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To  achieve  data  sharing  among  heterogeneous  database  management  systems,  one 
essential  step  is  the  conversion  of  the  schemata  defined  in  the  diverse  data  models  used  by 
these  systems.  A  semantic  preserving  translation  of  different  modeling  constructs  and 
constraints  is  necessary  to  ensure  that  the  semantics  of  applications  remain  intact  after  the 
translation.  However,  it  is  difficult  to  translate  the  constructs  and  constraints  of  one  model 
directly  into  those  of  another  model  because  1)  their  terminologies  and  modeling  constructs 
are  often  different  and  2)  being  high-level  user-oriented  models,  their  modeling  constructs 
may  have  a  lot  of  implied  semantic  properties  which  may  or  may  not  correspond  to  those  of 
the  others.  If  these  high-level  constructs  and  constraints  are  decomposed  into  some  low- 
level,  neutral,  primitive  semantic  representations,  then  a  system  can  be  built  to  compare 
different  sets  of  primitives  in  order  to  identify  whether  these  constructs  and  constraints  are 
identical,  slightly  different,  or  totally  unrelated.  Discrepancies  among  them  can  be  explicitly 
specified  by  the  primitive  representations  and  be  used  in  the  application  development  to 
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account  for  the  missing  semantics.  This  dissertation  contributes  to  the  development  of  an 
object-oriented  rule-based  extensible  core  model  (ORECOM)  which  is  used  as  a  neutral, 
intermediate  model  through  which  diverse  modeling  constructs  and  constraints  are 
translated. 

The  core  model  provides  a  small  number  of  general  structural  constructs  for 
representing  the  structural  properties  of  high-level  modeling  constructs  including  those  of 
object-oriented  data  models.  It  also  provides  a  powerful  knowledge  rule  specification 
language  for  defining  those  semantic  properties  not  captured  by  the  general  structural 
constructs.  The  language  is  calculus-based  and  allows  complex  semantic  constraints  to  be 
defined  in  terms  of  triggers  and  the  alternative  actions  to  be  taken  when  some  complex  data 
conditions  have  or  have  not  been  satisfied.  This  dissertation  also  presents  eight  basic 
constraint  types  found  in  many  semantically  rich  data  models  including  IDEF-1X, 
EXPRESS,  NIAM,  and  OSAM*.  These  constraint  types  are  represented  in  the  neutral 
model  by  parameterized  macros  and  their  corresponding  semantic  rules.  Parameterized 
macros  are  compact  forms  of  neutral  semantic  representations  which  are  used  in  an 
implemented  system  for  comparing  and  translating  the  modeling  constructs  and  constraints 
of  different  data  models.  The  corresponding  semantic  rules  are  the  detailed  semantic 
descriptions  of  the  constraint  types. 

The  modeling  constructs  and  constraints  of  the  above  mentioned  data  models  have 
been  analyzed  and  decomposed  into  the  macro-  and  micro-rule  representations  which  are 
used  in  the  design  and  implementation  of  a  data  model  and  schema  translation  system.  In 
addition  to  schema  translations,  several  applications  of  the  neutral  core  model  and  the 
translation  system  including  data  model  learning,  schema  integration,  schema  verification 
and  optimization  are  also  described. 
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CHAPTER  1 
INTRODUCTION 

1.1  Motivation 

Recent  progress  in  computer  networking  technologies  and  fast-emerging  non- 
traditional  applications  have  created  an  increased  need  for  an  integrated  or  federated 
computing  system  to  achieve  more  coordination  and  interoperability  of  heterogeneous 
systems  [GUP89,  LIT90,  SHE90,  THO90,  HSI92a,  HSI92b].  The  main  feature  of  such 
an  integrated  or  federated  computing  system  is  that  the  data  and  schemata  of  all  component 
systems  can  be  shared  and  interchanged  among  multiple  divisions  of  an  enterprise  or 
multiple  enterprises.  This  feature  has  been  shown  to  be  increasingly  important  for 
supporting  the  business  activities  of  present  and  future  organizations.  It  is  critical  for 
effectively  reducing  product  or  application  development  costs,  helping  to  strengthen  an 
organization's  functionalities,  and  therefore  increasing  the  competitiveness  of  their  products 
in  the  world  market. 

In  an  integrated  or  federated  computing  environment,  the  data  and  schemata  have 
usually  been  independently  developed  for  supporting  different  aspects  of  applications  using 
different  computing  and  database  systems.  The  main  barrier  to  effective  data  and  schema 
sharing  is  the  rapid  proliferation  and  heterogeneity  of  data  models  and  data  management 
systems.  For  example,  in  a  manufacturing  environment,  data  used  to  support  various 
designs,  process  planning,  and  manufacturing  activities  are  often  defined  by  different  data 
models  and  stored  and  processed  by  different  file  management  systems,  database 
management  systems,  and  in-house  software  of  all  kinds.  They  have  different  logical  as 
well  as  physical  structures  and  are  processed  by  different  application  programs  which  run 
on  different  hardware  systems  and  operating  systems.  To  share  the  data  generated  by 
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different  activities  of  the  entire  product  life  cycle  starting  from  product  design,  analysis, 
process  planning,  manufacturing,  sale,  and  service,  a  heterogeneous  database  management 
system  (HDBMS)  needs  to  be  developed  to  run  on  top  of  the  existing  data  management 
facilities  used  by  a  manufacturing  enterprise.  According  to  the  three-layered  structure  of  a 
HDBMS  [ELM90],  a  HDBMS  must  be  able  to  perform  the  following  functions  to  achieve 
the  interoperability:  (1)  convert  different  data  models  and  query  languages,  (2)  translate  and 
integrate  schemata,  and  (3)  process  global  as  well  as  local  transactions.  Above  all  things,  it 
must  be  able  to  translate  the  logical  (schema)  and  physical  (data)  representations  of  the  data 
residing  on  one  component  system  into  the  representation  suitable  for  use  by  another 
component  system.  The  translation  of  logical  schemata  is  essential  for  achieving  data 
sharing  and  improving  interoperability  among  heterogeneous  component  systems.  Other 
problems  and  solutions  related  to  many  issues  of  interoperability  among  heterogeneous 
systems  have  been  well  addressed  and  documented  [HEI85,  LIT86,  NSF89,  SHE90, 
AL091,  GAN91,  KEN91,  URB91,  KRI91,  BAR92,  BEN92]. 

Although  there  has  been  much  work  on  the  research  and  development  of  logical 
schema  translation,  most  of  the  existing  work  has  been  limited  to  traditional  data  models 
(e.g.,  hierarchical,  network,  and  relational  models)  [BIL79,  VAS80,  CAR80a,b,  LAR83, 
HWA83,  etc.]  In  today's  complex  and  nontraditional  applications  such  as  CAD/CAM, 
office  automation,  knowledgebases,  multimedia  data  management,  integrated 
manufacturing  and  so  on,  the  translation  becomes  more  difficult  because  the  schemata  of 
different  applications  are  defined  by  much  more  complex  high-level  object-oriented  and 
semantic  models  such  as  EXPRESS  [SCH89,  IS092],  NIAM  [VER82],  IDEF-1X 
[LOO86,  87],  OSAM*  [SU89],  and  others  surveyed  in  [HUL87,  PEC88].  Each  of  these 
models  has  different  modeling  constructs  (e.g.,  entity  or  class,  object  or  instance,  relation 
or  association,  etc.)  for  modeling  the  structural  properties  of  an  application.  These 
constructs  often  have  a  number  of  semantic  constraints  associated  with  them.  They  are 
either  explicitly  specified  by  some  keywords  or  rules  (e.g.,  primary  key,  non-null,  total 
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participation,  one-to-one  mapping,  etc.)  or  implicitly  represented  by  the  constructs  (e.g.,  all 
instances  of  a  subtype  entity  are  also  members  of  a  supertype  entity).  Furthermore,  some 
models,  especially  object-oriented  models  (e.g.,  OSAM*  and  EXPRESS),  also  allow  the 
encapsulation  of  user-defined  operations  and  rules  for  modeling  the  behavioral  properties 
of  an  application.  Different  data  models  may  also  name  their  constructs  and  constraints 
differently  even  though  they  may  represent  the  same  semantic  properties.  Others  may  have 
the  same  names  but  refer  to  totally  different  properties.  In  addition,  constructs  and 
constraints  of  different  models  may  share  similar  but  not  identical  properties.  All  of  these 
phenomena  are  referred  to  as  the  data  inconsistency  problem,  which  is  called  the  domain 
mismatch  problem  [BRE90]  or  representational  heterogeneity  problem  [GAN91]. 
These  data  inconsistencies  or  semantic  discrepancies  create  great  difficulties  in  data 
conversion,  query  translation,  schema  integration  as  well  as  transaction  execution  in 
heterogeneous  systems.  They  need  to  be  fully  accounted  for  when  data  of  one  system  are 
accessed  by  another  system  so  that  no  semantic  properties  will  be  lost.  Thus,  the  analysis 
of  semantic  properties  underlying  the  existing  modeling  constructs  and  the  identification  of 
the  semantic  similarities  and  differences  of  these  constructs  are  the  fundamental  problems 
that  need  to  be  solved  before  the  true  interoperability  of  heterogeneous  database  systems 
can  be  achieved. 

Motivated  by  the  above  problems,  we  have  studied  a  number  of  popular  data 
models  in  an  attempt  to  identify  the  underlying  semantic  properties  of  their  modeling 
constructs  and  their  associated  constraints.  The  objective  is  to  use  their  common  properties 
and  differences  as  a  basis  for  the  design  and  development  of  a  neutral  data  model  through 
which  the  modeling  constructs  and  constraints  of  one  model  can  be  converted  into  those  of 
another,  and  semantic  discrepancies,  if  they  exist,  can  be  identified  and  specified  explicitly. 
These  discrepancies  can  be  used  for  the  generation  of  explanations  and  can  be  used  by 
application  developers,  who  use  the  converted  schemata  and  databases,  for  incorporation 
into  the  new  application  systems  so  that  no  semantic  loss  will  result.  If  these  discrepancies 
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can  be  specified  in  enough  detail,  they  can  also  be  used  for  automatic  generation  of  a 
program  code  which  can  be  incorporated  into  the  new  application  systems. 

1.2  General  Approach 

Our  main  approach  to  solve  the  data  inconsistency  problem  is  first  to  develop  a 
neutral  core  model  which  provides  some  primitive  modeling  constructs  and  then  to 
decompose  the  complex  semantic  properties  of  high-level  modeling  constructs  and 
constraints  into  the  primitive  constructs  of  the  core  model.  The  objective  of  the 
decomposition  is  to  precisely  capture  the  structural  and  behavioral  properties  captured  by 
the  existing  data  models  in  order  to  explicitly  identify  and  represent  the  similarities  and 
differences  among  these  data  models.  A  core  model,  called  ORECOM.  has  been  developed 
to  serve  this  purpose.  It  is  an  object-oriented,  rule-based,  extensible  core  model 
which  provides  a  few  very  general  structural  constructs  and  a  powerful  rule  specification 
facility  for  specifying  primitive  semantic  properties.  The  high-level  modeling  constructs  of 
the  existing  data  models  can  then  be  decomposed  and  represented  by  ORECOM's  primitive 
structural  constructs  and  semantic  rules.  By  comparing  their  low-level  neutral 
representations,  the  semantic  discrepancies  of  high-level  constructs  can  thus  be  identified 
and  explicitly  specified  by  semantic  rules.  In  ORECOM,  these  rules  are  called  micro- 
rules,  which  allow  the  specification  of  database  operations  (the  trigger  conditions)  under 
which  certain  detailed  database  states  need  to  be  verified  to  determine  the  alternative 
database  operations  to  be  taken  based  on  the  result  of  the  verification.  A  calculus-based 
language  is  used  as  the  rule  specification  language.  For  the  convenience  of  expressing  the 
semantic  constraint  types  frequently  found  in  data  models  and  for  avoiding  the  repeated 
specifications  of  these  constraint  types  in  terms  of  detailed  micro-rules,  we  use 
parameterized  macros  to  represent  them.  Each  macro  captures  a  generic  constraint  type 
(e.g.,  cardinality)  and  its  variations  are  specified  by  the  parameters  of  the  macro.  Thus,  a 
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macro  corresponds  to  sets  of  micro-rules  which  define  the  constraint  type  and  its 
variations.  In  this  dissertation  (Chapter  6),  examples  of  high-level  modeling  constructs 
taken  from  several  semantically  rich  data  models  such  as  IDEF-1X,  NIAM,  EXPRESS, 
and  OSAM*  are  used  to  show  how  they  can  be  mapped  into  the  underlying  ORECOMs 
macro-  and  micro-rule  representations  through  semantic  decompositions.  The  first  three 
models  have  been  used  by  many  industrial  companies  for  product  specification  and 
exchange.  They  are  of  great  interest  to  the  industrial  community  involved  in  STEP1  and 
IGES/PDES2  activities  in  developing  an  international  standard.  OSAM*  is  an  object- 
oriented  semantic  association  model  developed  at  the  University  of  Florida.  A  knowledge- 
base management  system  OSAM*.KBMS  has  been  implemented  based  on  this  data  model 
for  supporting  advanced  data/knowledge  base  applications. 

The  major  contributions  of  this  research  are  (1)  the  introduction  of  an  object- 
oriented,  rule-based,  extensible  core  model  (ORECOM)  which  is  used  to  represent  in  a 
neutral  form  the  semantic  properties  of  diverse  high-level  modeling  constructs  and 
constraints,  (2)  the  formalization  of  some  basic  constraint  types  (i.e.,  macros)  which 
provide  the  needed  semantic  foundation  for  data  model  analysis,  and  (3)  the  development 
of  a  semantics-preserving  schema  translation  technique  and  system. 

1.3  Dissertation  Organization 

The  rest  of  this  dissertation  is  organized  as  follows.  Chapter  2  surveys  the  related 
work  in  the  schema  translation  area  with  emphasis  on  the  following  two  aspects:  translation 
capability  and  translation  approach.  In  Chapter  3,  we  present  the  approach  for  data  model 
analysis  based  on  the  concept  of  semantic  decomposition  and  the  use  of  a  neutral  core 
model.  In  Chapter  4,  we  describe  the  structural  primitives  and  behavioral  primitives  of  the 

JSTEP  (the  Standard  for  the  Exchange  of  Product  Model  Data)  is  a  project  under 
development  by  the  ISO  Technical  Committee  184  (TC184)  /Sub-Committee  4  (SC4). 
2IGES  (Initial  Graphics  Exchange  Specification)  and  PDES  (Product  Data  Exchange 
Specification)  are  U.S. -based  contributors  to  the  development  of  STEP. 
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neutral  core  model  ORECOM.  The  macro  representations  of  basic  constraint  types  are 
described  in  Chapter  5.  The  use  of  ORECOM  macros  in  performing  data  model  analysis  of 
IDEF-1X,  EXPRESS,  NIAM,  and  OSAM*  is  given  in  Chapter  6.  In  addition  to  the  data 
model  analysis,  other  applications  of  ORECOM  are  also  discussed.  In  Chapter  7,  we 
present  the  design  and  implementation  of  a  schema  translation  system  which  uses 
ORECOM  as  a  neutral  model.  Finally,  Chapter  8  gives  our  conclusion  of  this  research  and 
outlines  the  future  directions. 


CHAPTER  2 
SURVEY  OF  RELATED  WORK 


In  this  chapter,  a  survey  of  some  related  work  on  data  model  and  schema  translation 
is  given.  The  survey  and  the  discussion  will  be  concentrated  on  two  aspects:  the  translation 
capability  and  the  translation  approach.  On  translation  capability,  we  are  concerned  with  the 
data  models  and  the  directions  of  translations  that  are  supported  by  a  translation  system.  On 
translation  approach,  we  compare  the  direct  approach  with  the  indirect  approach  of 
translation.  The  result  of  our  survey  is  summarized  in  the  table  shown  in  Table  2. 1 . 

2. 1  Translation  Capability 

Most  of  the  existing  work  on  data  model  and  schema  translation  were  developed  in 
the  early  80's  and  focused  on  the  transformations  among  the  traditional  data  models  only 
(i.e.,  hierarchical,  network,  and  relational  models).  Some  of  them  can  transform  in  both 
directions,  i.e.,  schemata  expressed  in  any  one  of  the  three  models  to  that  of  the  others 
[BIL79,  CAR80a,b,  POT84,  GRA84,  JAC85,  BRE86,  CAR87].  Some  can  perform  only 
specific  transformations,  for  example,  between  the  relational  and  network  models  [DEV80, 
KAT80,  LAR83],  or  from  the  hierarchical  and  network  models  to  the  relational  model 
[VAS80,  HWA83]. 

In  recent  years,  the  fast  growing  demand  for  database  support  for  complex  and 
non-traditional  applications  such  as  CAD/CAM,  computer  integrated  manufacturing  (CIM), 
office  automation,  and  multi-media  system,  etc.,  has  spurred  the  introduction  of  a  number 
of  new  high-level  data  models  such  as  semantic  data  models  exemplified  by  E-R  [CHE761, 
EER  [ELM89],  E2/R  [OZK90],  NIAM[VER82]  and  EXPRESS  [SCH89,  IS092],  and 
object-oriented  data  models  used  in  Iris  [FIS87],  and  02  [BAN88],  etc.  It  also  motivated 
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more  research  on  data  model  and  schema  translation.  For  example,  in  the  work  of  Elmasri 
and  Navathe  [ELM89],  E-R  and  EER  models  can  be  transformed  to  one  of  the  traditional 
models.  Similarly,  the  translation  between  E2/R  model  and  the  traditional  models  has  also 
been  studied  [OZK90].  Bidirectional  translations  between  the  E-R  model  and  the  traditional 
models  [SEN86]  and  between  EXPRESS  and  the  extended  E-R  model  [SAN92]  are 
available.  Translation  in  a  heterogeneous  database  system  involving  the  functional  data 
model  [SHI81]  and  the  traditional  models  has  been  reported  [DEM87,88,  HSI89].  To 
name  a  few  more,  there  are  transformations  from  NIAM  to  EXPRESS  [CHA92],  from 
NIAM  to  ACS  [FLY85],  from  Iris  to  the  relational  model  [LYN87],  from  NIAM  to  the 
relational  model  [LEU88],  and  from  E-R  to  the  relational  and  network  models  [BRI85], 
etc.  However,  to  our  knowledge,  there  has  been  not  much  attempt  to  translate  schemata 
defined  by  high-level  semantically  rich  data  models  such  as  IDEF-1X,  EXPRESS,  NIAM, 
and  OSAM*.  Furthermore,  most  of  the  existing  work  does  not  handle  bi-directional 
transformations.  None  of  the  existing  translation  systems  can  be  easily  extended  or 
modified  to  include  the  semantics  introduced  in  new  models. 

2.2  Translation  Approach 

As  far  as  the  translation  approach  is  concerned,  a  model/schema  translation  can  be 
performed  either  directly  or  indirectly.  In  the  direct  translation  approach  illustrated  by 
Figure  2.1(a),  the  translation  of  one  model  to  another  is  carried  out  by  applying  a  dedicated 
translation  algorithm  which  is  designed  to  satisfy  only  the  conversion  requirements  of  a 
particular  pair  of  models.  Therefore,  it  can  not  be  used  for  the  translation  of  a  different  pair. 
For  instance,  in  Figure  2.1(a),  the  algorithm  for  transforming  model  A  to  model  C  can  not 
be  used  for  other  transformations  (e.g.,  from  A  to  B,  from  A  to  D,  or  from  C  to  A). 
Consequently,  the  mapping  between  E-R  and  the  relational  model  as  described  in  [VAS80] 
needs  two  different  algorithms;  one  for  each  direction.  Similarly,  the  mappings  between  E- 
R,  EER,  or  E2/R  and  the  relational,  hierarchical,  or  network  model  [ELM89,OZK90],  Iris 
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and  the  relational  model  [LYN87],  NIAM  and  the  relational  model  [LEU88],  NIAM  and 
ACS  [FLY85],  the  relational  model  and  the  network  model  [LAR83],  etc.,  all  need 
different  translation  or  mapping  algorithms.  There  is  no  uniform  approach  to  support  the 
algorithm  development  for  different  transformations. 


(a)  Direct  translation 


Model  A 


Model  B 


Model  D 


Intermediate 
Representation 

Common 

Transformation  Rules 


Model  C 


(b)  Indirect  translation 


Figure  2. 1  Two  different  translation  approaches. 


The  indirect  translation  approach,  on  the  other  hand,  avoids  the  development  of  a 
large  number  of  unsharable  translation  algorithms  by  using  a  common  intermediate  model. 
Instead  of  transforming  a  source  model  to  a  target  model  directly,  it  divides  the  translation 
into  two  steps.  In  the  first  step,  the  source  model  is  converted  into  an  intermediate 
representation  which  is  then  converted  into  the  target  model  in  the  second  step.  Clearly, 
only  two  sets  of  algorithms  are  needed;  one  for  each  step  of  the  translation.  By  these  two 
sets  of  algorithms,  any  source  model  can  be  transformed  to  any  target  model  without 
additional  algorithms.  The  concept  of  indirect  translation  is  illustrated  in  Figure  2.1(b). 

For  a  translation  system  that  handles  a  few  data  models,  a  direct  translation  can  be  a 
good  approach  from  the  performance  point  of  view  because  of  its  dedicated  translation 
algorithms.  However,  for  a  large  system  containing  many  different  models,  an  indirect 
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translation  approach  is  more  appropriate.  There  are  at  least  two  significant  advantages.  (1) 
Low  complexity  -  For  N  data  models,  N*(N-1)  dedicated  translation  algorithms  have  to 
be  developed  and  implemented  in  the  direct  approach.  Only  2N  algorithms  are  needed  for 
the  indirect  approach.  The  order  of  complexity  of  direct  transformations  is  O(N^)  as 
compared  with  O(N)  of  the  direct  translation  [SEN86].  (2)  High  extensibility  --  To  add 
a  new  model  into  a  translation  system  that  can  handle  schema  translation  of  N  models,  only 
two  new  translation  algorithms  need  to  be  added  using  the  indirect  approach;  one  for  each 
direction  between  the  new  model  and  the  intermediate  model.  In  the  case  of  direct 
translation,  2N  new  algorithms  are  needed.  The  indirect  approach  is  obviously  more 
advantageous  than  the  direct  approach. 

To  use  the  indirect  translation  approach,  an  important  decision  to  be  made  is  on  the 
selection  of  an  intermediate  model.  In  the  work  we  surveyed,  many  existing  or  specially 
designed  data  models  have  been  used  as  the  intermediate  model.  The  E-R  model  in  HD- 
DBMS  [CAR80a,b,  87],  the  functional  model  in  Multibase  [SMI81],  the  ECR  in  DDTS 
[DEV80],  the  IDEF-1X  in  IISS  [IIS83],  the  attribute-based  model  in  MLDS  [DEM87,88, 
HSI89],  the  OSAM*  in  IMDAS  [KIR88],  the  canonical  model  in  PRECI  [DEE81],  and  the 
EXPRESS  in  SUMM  [FUL92]  are  just  some  examples.  Other  representations  are  also 
possible.  For  example,  the  first-order  logic  is  used  in  Jacobs  [JAC85]  and  Grant  [GRA84], 
a  Logical  Data  Definition  Language  (LDDL)  is  developed  by  Biller  [BIL79],  a  hypergraph 
is  considered  by  Morgenstern  [MOR83],  and  mathematically  precise  definitions  are 
proposed  by  Klug  [KLU78].  The  selection  of  an  intermediate  model  is  important  because  it 
not  only  determines  the  capability  of  a  translation  system  but  also  affects  the  correctness  of 
the  result.  For  example,  if  a  data  model  has  some  constructs  or  constraints  that  can  not  be 
captured  by  the  selected  intermediate  model,  then  the  semantic  properties  can  not  be 
preserved  in  the  translation.  For  achieving  correct  transformations,  an  effective  mechanism 
is  also  needed  to  handle  semantic  discrepancies  of  the  source  and  target  constructs.  It  has  to 
first  identify  the  differences  and  represent  them  precisely  in  some  form  such  as  rules  that 
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can  be  used  for  generating  explanations  or  a  program  code  to  account  for  the  discrepancies. 
Otherwise,  semantic  lossless  translations  can  not  be  guaranteed. 

We  can  categorize  the  existing  intermediate  models  into  two  groups:  high-level  data 
models  and  low-level  data  models.  Using  a  high-level  (usually  semantic  or  object-oriented) 
data  model  as  the  intermediate  model  can  be  viewed  as  a  "super  model"  approach.  This 
approach  aims  to  incorporate  the  modeling  concepts  of  the  existing  data  models  in  the 
intermediate  model  so  that  it  can  "subsume"  all  the  existing  data  models.  There  are  several 
examples  of  this  approach  such  as  the  E-R  model  [POT84,  CAR80a,b,  87],  the  functional 
model  [SMI81],  the  XER  model  [MAR83],  and  the  EXPRESS  [ALM92,  CLE92, 
FUL92].  However,  such  a  super  model  is  generally  difficult  to  achieve  and  is  impractical 
for  the  following  reasons.  First,  it  is  difficult  for  a  single  model  to  effectively  incorporate  in 
a  "seamless"  manner  all  the  constructs  and  constraints  of  the  existing  data  models  which 
have  different  complexities  and  incompatible  features.  Second,  the  resulting  model,  even  if 
it  can  be  developed,  would  be  too  complicated  for  use.  Furthermore,  it  is  virtually 
impossible  to  anticipate  and  accommodate  the  changing  requirements  for  modeling 
application  data  (i.e.,  new  semantic  properties)  even  if  a  complete  set  of  modeling 
constructs  and  constraints  can  be  defined  based  on  the  existing  models. 

Using  a  low-level  data  model  as  the  intermediate  model  seems  to  be  a  more  suitable 
approach.  A  low-level  data  model  is  one  that  provides  a  set  of  primitive,  general,  and 
neutral  constructs.  For  precise  semantic  specifications,  high-level  modeling  constructs  of 
the  existing  data  models  can  be  decomposed  and  represented  by  these  primitive  constructs 
and  their  discrepancies  can  be  identified  by  matching  the  sets  of  low-level  constructs.  The 
work  of  Grant  [GRA84]  and  Jacobs  [JAC85]  is  a  good  example.  Grant  and  Jacobs 
developed  a  database  logic  for  data  model  and  database  transformations.  The  IM  model 
[SEN86]  and  the  attribute-based  model  [DEM87,88,  HSI89]  are  another  two  examples  of 
using  primitive  constructs  and  operations  to  handle  data  model  transformations.  However, 
these  intermediate  models  were  used  to  capture  the  semantic  properties  of  the  traditional  and 
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functional  data  models.  They  are  not  adequate  for  capturing  the  complex  structural  and 
behavioral  properties  of  new  object-oriented  data  models. 

As  a  general  conclusion  of  this  survey,  we  believe  that  (1)  the  indirect  approach  of 
model/schema  translation  is  less  complicated  and  more  extensible,  and  (2)  a  low-level 
model  is  necessary  to  support  the  analysis  of  complex  semantic  properties  of  high-level 
data  models  and  to  effectively  handle  the  semantic  discrepancies  found  in  the  modeling 
constructs  and  constraints  of  the  existing  data  models. 
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Table  2.1  Related  work  on  data  model  and  schema  translation. 


Capability 

Approach 

Source 

Target 

Direction 

Direct  / 
Indirect 

Intermediate 
Model 

Applications 

Ozkarahan 

E2/R 

R.H.N 

1-D 

Direct 

— 

multi-model 

HzitsH^co  cuctom 

Elmasri  &  Navathe 

r  | —  ■    1  inn] 

[ELM89] 

ER 
EER 

R,H,N 

1-D 

Direct 

— 

model  comparison 
&  database  design 

Vassiliou  & 
Lochovsky 
[VAS80] 

H,  N 

R 

1-D 

Direct 

— 

transaction 
translation 

Katz 
[KAT80] 

R 

N 

2-D 

Direct 

— 

model  translation 
&  database  design 

Sen 

[SEN86] 

R.H.N 
ER 

R.H.N 
ER 

2-D 

Indirect 

IM 

Data  Model 

schema  translation 

Demurjian  &  Hsiao 

[DEM87.88] 

[HSI89] 

R,H,N,F 

R.H.N.F 

2-D 

Indirect 

attribute- 
based  Model 

heterogeneous 
databases 

Potter 
[POT84] 

R.H.N 

R.H.N 

2-D 

Indirect 

ER 

multi-model 
schema  design 

Smith 
[SMI81] 

R.N.file 

R.N.file 

2-D 

Indirect 

functional/ 
DAPLEX 

database 

integration 

(Multibase) 

Devor 
[DEV80] 

R,N 

R,N 

2-D 

Indirect 

ECR/ 
GORDAS 

database 
integration 
(DDTS) 

Jacobs  &  Grant 
[JAC85]  [GRA84] 

R,H,N 

R.H.N 

2-D 

Indirect 

database 
logic 

database  conversion 
&  view  integration 

Navathe  &  Cheng 
[NAV83] 

EER 

H 

1-D 

Direct 

schema  translation 

Hwang  &  Dayal 
[HWA83] 

H,  N 

R 

1-D 

Indirect 

ER/ 
ERL 

multi-model 
database  system 

Dumpala  &  Arora 
[DUM83] 

R,H,N 

ER 

2-D 

Direct 

multi-model 
database  system 

(  R  :  relational    H  :  hierarchical    N  :  network    F:  functional    1-D  :  unidirectional    2-D  :  bidirectional ) 
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Table  2. 1  (continued). 


Capability 

Approach 

Applications 

Source 

Target 

Direction 

Direct  / 
Indirect 

Intermediate 
Model 

Biller 
[BIL79] 

R.H.N 

R.H.N 

2-D 

Indirect 

LDDL 

data  translation 

Flynn  &  Laender 
[FYY85] 

NIAM 

ACS 

1-D 

Direcl 

schema 
comparison 

Cardnenas 
[CAR80a,b,87] 

R,H,N 

R,H,N 

2-D 

Indirect 

ER+DIAM 

heterogeneous 
database  system 
(HD-DBMS) 

Breitbart 
[BRE86] 

Morgenstern 
[MOR83] 

R.H.N 

R,H,N, 
entity- 
based 

R.H.N 

R,H,N, 
entity- 
based 

2-D 
2-D 

Indirect 
Indirect 

extended 
relational 

hypergraph 

heterogeneous 
database  system 
(ADDS) 

schema  translation 

Deen 

[DEE80.81] 

R,N 
Adabas 

R,N 
Adabas 

2-D 

Indirect 

canonical 
data  model 

heterogeneous 
databases 
(PRECI) 

Lyngbaek  &  Vianu 
[LYN87] 

Iris 

R 

1-D 

Direct 

— 

schema 
comparison  & 
optimization 

Leung  &  Nijssen 
[LEU88] 

NIAM 

R 

1-D 

Direct 

— 

database  design 

Briand,  et  al. 
[BRI85] 

ER 

R,  N 

1-D 

Direct 

database  design 

Larson 
[LAR83] 

R 

N 

2-D 

Direct 

multi-model 
database  system 

Margrave  et  al. 
[MAR83] 

ER 

IMS 
IDMS 
ADABAS 
TOTAL 

1-D 

Indirect 

XER 

database  design 

(  R  :  relational    H  :  hierarchical    N  :  network   F  :  functional    1-D  :  unidirectional   2-D  :  bidirectional ) 


CHAPTER  3 

AN  APPROACH  TO  DATA  MODEL  ANALYSIS  AND  TRANSLATION 


As  concluded  from  the  previous  chapter,  we  know  that  it  is  difficult  to  translate  the 
constructs  and  constraints  of  one  model  directly  into  those  of  another  model  because  1 ) 
their  terminologies  and  modeling  constructs  are  often  different  and  2)  being  high-level  user- 
oriented  models,  their  modeling  constructs  may  have  a  lot  of  implied  semantic  properties 
which  may  or  may  not  correspond  to  those  of  the  others.  If  these  high-level  constructs  and 
constraints  are  decomposed  into  some  low-level,  neutral,  primitive  semantic 
representations,  then  a  system  can  be  built  to  compare  different  sets  of  primitives  in  order 
to  identify  whether  these  constructs  and  constraints  are  identical,  slightly  different,  or 
totally  unrelated.  Discrepancies  among  them  can  be  explicitly  specified  by  the  primitive 
representations  and  be  used  in  the  application  development  to  account  for  the  missing 
semantics.  To  support  the  above  semantic  decomposition  of  high-level  data  models  and  to 
facilitate  the  translations  of  the  schemata  defined  on  these  data  models,  a  neutral  low-level 
core  model  is  required.  This  model  must  be  very  primitive  so  that  it  can  be  used  to  capture 
the  structural  and  behavioral  properties  of  other  high-level  data  models.  In  this  chapter,  we 
shall  first  present  the  concept  of  semantic  decomposition  and  then  discuss  the  required 
characteristics  of  the  neutral  data  model. 

3.1  Semantic  Decomposition 

For  the  convenience  of  database  users,  all  existing  data  models  are  designed  in  such 
a  way  that  they  provide  a  number  of  high-level  structural  constructs  for  defining  the 
structural  properties  (attributes  and  relationships)  of  real  world  entities.  Associated  with 
these  constructs,  there  are  a  number  of  constraints  (keys,  non-null,  total  participation, 
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cardinality,  etc.)  which  are  either  explicitly  specified  by  some  reserved  keywords  or 
implicitly  specified  in  the  structures  for  expressing  various  semantic  restrictions  that  should 
be  enforced  by  DBMSs.  Due  to  the  fact  that  these  modeling  constructs  are  high-level  and 
user-oriented,  they  often  carry  a  lot  of  semantics  which  may  or  may  not  be  equivalent  to 
those  in  the  modeling  constructs  of  another  data  model.  For  example,  the  association 
between  two  entity  types  in  the  relational  model  is  expressed  by  means  of  a  cross  reference 
between  keys  and  foreign  keys,  and  the  referential  constraint  can  be  implemented  in  a 
DBMS  using  different  deletion  rules,  whereas,  in  the  entity-relationship  or  ER  model 
[CHE76],  the  association  is  explicitly  modeled  by  a  relationship  which  implicitly  uses 
cascaded  deletion  for  implementing  the  referential  constraint.  As  another  example,  the 
generalization  construct  or  superclass-subclass  association  between  two  entity  types  in  all 
object-oriented  data  models  implies  the  property  of  inheritance  yet  their  inheritance  models 
can  be  rather  different  and  thus  have  different  implied  object  insertion  and  deletion 
behaviors.  Due  to  these  and  many  other  types  of  differences,  a  direct  translation  between 
modeling  constructs  and  constraints  of  different  data  models  is  not  workable  since  many 
fine  semantic  distinctions  can  not  be  captured  and  there  will  be  semantic  losses  or  additions 
in  the  translation.  In  order  to  achieve  a  semantic-preserving  translation,  it  is  necessary  to 
decompose  a  modeling  construct  and  its  associated  constraints  into  some  low-level 
structural  and  behavioral  primitives  which  can  then  be  used  for  comparing  the  modeling 
constructs  and  constraints  of  different  models  and  used  to  explicitly  represent  their 
discrepancies. 

3.2  Support  of  a  Neutral  Core  Model 

The  existing  user-oriented  data  models  use  different  terminologies  to  name  all 
things  of  interest  in  an  application  world  (e.g.,  entities,  objects,  concepts,  tuples,  etc.)  and 
the  collections  of  these  things  (e.g.,  entity  types,  object  types  or  classes,  concept  types, 
relation,  etc.).  They  also  use  different  terms  to  specify  the  structural  relationships  among 
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these  collections  (e.g.,  attributes,  instance  variables,  associations,  relationships,  bridges, 
links,  etc.).  In  order  to  map  the  structural  constructs  to  a  neutral  representation,  the  neutral 
model  should  adopt  a  general  terminology  to  name  things  and  their  relationships.  It 
should  also  provide  a  number  of  very  primitive  structural  constructs  so  that  the  basic 
structural  properties  of  high-level  data  models  can  all  be  represented  by  these  primitives. 
Those  semantic  properties  in  these  high-level  constructs  that  are  not  captured  by  these 
structural  primitives  can  be  specified  using  a  knowledge  specification  language.  The 
separation  of  structural  primitives  from  detailed  semantic  specifications  using  a  rule 
language  is  important  since  the  former  provides  a  common  structural  representation  and  the 
latter  can  be  used  to  explicitly  state  the  different  semantic  properties  associated  with 
different  high-level  constructs. 

In  any  database  management  system,  the  semantics  of  modeling  constructs  and 
constraints  of  a  data  model  can  be  stated  in  terms  of  what  the  DBMS  should  do  when  data 
defined  by  these  constructs  and  constraints  are  retrieved  and  manipulated.  In  other  words, 
their  semantic  properties  can  be  defined  by  the  conditions  under  which  certain  actions  need 
to  be  taken  by  the  DBMS.  For  example,  part  of  the  meaning  of  a  key  attribute  is  that,  upon 
the  insertion  of  an  entity  instance  (or  a  tuple  of  a  relation)  or  the  update  of  a  key  attribute 
value,  the  DBMS  needs  to  verify  that  its  key  attribute  value  is  different  from  those  of  the 
other  instances.  As  another  example,  part  of  the  semantics  of  a  superclass-subclass 
association  is  that,  upon  the  deletion  of  a  superclass  object,  the  corresponding  object 
instances  in  all  their  subclasses  in  the  class  hierarchy  or  lattice  need  to  be  deleted  also. 
Thus,  the  semantics  of  data  models  can  be  defined  in  terms  of  the  "operational  semantics" 
of  a  DBMS  rather  than  the  semantics  of  words  and  languages  that  linguists  and 
philosophers  are  interested  in. 

For  the  purpose  of  data  model  and  schema  translation,  the  neutral  model  should  be 
"low-level"  enough  to  allow  the  subtle  semantic  differences  among  data  models  to  be 
distinguished,  yet  "high-level"  enough  so  that  the  comparison  between  the  neutral 
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representations  of  the  modeling  constructs  or  constraints  of  any  two  data  models  can  be 
easily  carried  out  by  a  translation  system. 

In  the  neutral  model  to  be  described  in  the  next  chapter,  we  adopt  the  object- 
oriented  paradigm  for  structural  representation  due  to  its  generality  and  use  a  calculus-based 
knowledge  rule  specification  language  which  uses  triggers  and  patterns  of  object 
associations  for  the  specification  of  operational  semantics  associated  with  modeling 
constructs  and  constraints. 


CHAPTER  4 

THE  OBJECT-ORIENTED  RULE-BASED  EXTENSIBLE  CORE  MODEL  (ORECOM) 

ORECOM  stands  for  an  object-oriented,  rule-based,  and  extensible  core  model.  It  is 
a  low-level  neutral  data  model  designed  for  inter-model  and  schema  translation.  Its  object 
orientation  allows  all  things  of  interest  (e.g,  physical  objects,  abstract  things,  events, 
processes,  functions,  etc.)  to  be  represented  uniformly  in  terms  of  objects  and  object 
associations.  Its  rule  specification  facility  allows  complex  semantic  constraints  found  in  the 
existing  data  models  to  be  explicitly  specified  by  knowledge  rules  with  triggers.  Its 
extensible  feature  allows  new  semantic  properties  to  be  introduced  into  ORECOM  to 
account  for  the  possible  semantic  extensions  of  the  existing  models  or  the  introduction  of 
new  models.  The  extensible  feature  is  achieved  by  extending  the  model  of  the  model  (or  the 
meta-model)  using  knowledge  rules  and  methods.  It  has  been  reported  by  Yaseen 
[YAS91a,  b]  and  will  not  be  addressed  in  this  dissertation.  The  above  features  allow  the 
various  semantic  properties  (structural  and  behavioral)  of  data  models  to  be  explicitly 
defined  in  terms  of  ORECOM's  modeling  primitives. 

4.1  Structural  Primitives 

4.1.1  Object 

Object  is  the  atomic  unit  for  modeling  an  application  world.  It  can  represent  a 
physical  entity  such  as  a  building,  a  computer,  or  an  employee;  an  abstract  concept  such  as 
a  number,  a  project,  or  a  business  process;  an  event  such  as  an  employee  works  on  a 
project;  or  anything  of  interest  to  an  application.  Two  general  types  of  objects  are 
distinguished  in  ORECOM:  self-naming  objects  and  system-named  objects.  Self-naming 
objects  are  those  identified  by  their  values  such  as  integer  or  real  numbers,  character 
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strings,  or  some  structures  such  as  set,  bag,  list,  or  array  of  atomic  data  items  used  for 
defining  other  complex  self-naming  objects  or  system-named  objects.  System-named 
objects  are  those  of  interest  to  the  application  users  such  as  employees,  parts,  projects,  etc. 
They  are  uniquely  identified  by  system-assigned  object  identifiers  (OIDs)  and  are  described 
in  terms  of  self-naming  and/or  system-named  objects.  This  distinction  is  commonly  made 
in  data  models,  e.g.,  the  lexical  and  non-lexical  objects  in  NIAM,  and  domain  and  entity 
objects  in  OS  AM*. 

Another  way  of  distinguishing  objects  is  by  their  structures,  i.e.,  simple  objects  and 
complex  objects.  A  simple  object  represent  a  single  thing  or  concept  that  can  not  be  further 
decomposed  into  other  objects  with  respect  to  an  application  world.  A  complex  object,  on 
the  other  hand,  is  composed  of  other  simple  or  complex  objects  with  a  structure  such  as 
set,  list,  bag,  array,  tuple,  etc.,  or  their  mixture.  For  example,  a  list  of  five  to  ten 
employees  can  be  defined  to  be  a  complex  object  with  the  structure  'list[5,  10]'  and  an 
array  of  four  such  complex  objects  (e.g.,  array[-2,  1]  of  list[5,  10]  of  employee)  can  be 
further  formed  as  another  complex  object. 

4.1.2  Association 

An  association  is  a  bi-directional  link  connecting  two  objects.  It  specifies  that  the 
pair  of  objects  are  structurally  related.  However,  the  specific  semantic  properties  between 
them  such  as  a  system-named  object's  relationship  with  a  self-naming  object  (or  a  domain 
value)  through  an  attribute,  a  superclass  object's  relationship  with  its  representation  in  a 
subclass,  or  a  system-named  object's  relationship  with  another  system-named  object,  etc., 
are  not  represented  by  the  association.  In  ORECOM,  the  semantic  properties  of  an 
association  link  are  specified  by  micro-rules  (to  be  described  later).  This  separation  of  the 
general  structural  relationship  from  the  specific  semantic  properties  allows  heterogeneous 
data  modeling  constructs  to  be  mapped  to  the  neutral  structural  representation  and  their 
semantic  similarities  and/or  differences  to  be  explicitly  represented  by  micro-rules.  An  n- 
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nary  association  where  n  >  2  is  represented  by  n  number  of  binary  associations  and  the 
semantics  of  the  n-nary  relationship  is  again  captured  by  rules. 

An  association  in  ORECOM  is  labeled  by  an  association  name  as  well  as  the 
direction  of  the  association.  For  example,  a  company  object  (c)  hires  an  employee  object  (e) 
is  specified  by  "c  *>Hires  e"  where  the  symbol  "*"  represents  an  association,  ">" 
indicates  the  direction  of  the  association  from  c  to  e,  and  "Hires"  is  the  association  name. 
This  association  can  also  be  equivalently  represented  as  "c  *<Works_for  e"  where 
"Works_for"  is  the  inverse  of  "Hires".  The  name  of  an  association  is  the  same  as  an 
attribute  in  semantic  data  models  or  an  object  variable  in  object-oriented  data  models. 
Association  names  are  important  particularly  when  two  objects  are  related  by  more  than  one 
association  and  each  has  its  own  semantics.  For  instance,  "c  *>BeIongs_to  e"  and  "c 
*>Hires  e"  are  two  associations  with  different  meanings  between  the  same  pair  of 
objects. 

4.1.3  Class 

An  object  class  is  an  abstraction  of  or  a  type  specification  for  a  collection  of  object 
instances  which  share  some  common  structural  and  behavioral  properties.  Object  instances 
of  a  class  are  designated  uniquely  by  instance  identifiers  (i.e.,  IIDs)  each  of  which  is  a 
concatenation  of  a  class  identifier  (i.e.,  CID)  and  an  object  identifier  (i.e.,  OID).  Using  this 
identification  scheme,  the  same  real  world  object  which  can  be  identified  in  ORECOM  by 
its  OID  can  have  instances  in  different  classes  which  can  be  identified  by  their  IIDs. 
Corresponding  to  the  distinction  of  basic  object  types  made  in  many  existing  data  models, 
ORECOM  categorizes  object  classes  into  two  general  types:  entity-class  and  domain-class. 
An  entity-class  (or  E-class)  defines  the  structural  and  behavioral  properties  of  a  set  of 
system-named  objects.  It  also  serves  as  the  "container"  of  "holder"  of  a  set  of  object 
instances  which  are  the  data  representations  of  the  collection  of  objects  in  that  class.  In 
ORECOM,  an  E_class  is  defined  in  terms  of  a  class  name,  a  number  of  associations  with 
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other  classes,  a  set  of  method  specifications  (or  signatures)  and  their  implementations  for 
defining  the  "procedural  semantics"  implemented  in  program  code,  and  a  set  of  micro-rules 
for  defining  semantic  constraints  applicable  to  its  objects.  A  skeletal  class  definition  of  an 
Employee  class  is  given  in  Figure  4.1.  A  domain-class  (or  D-class)  in  ORECOM  defines  a 
set  of  self-naming  objects  (e.g.,  simple  self-naming  objects  such  as  integers,  reals,  etc.  or 
complex  self-naming  objects  such  as  a  list  of  integers,  an  array  of  reals,  etc.).  It  specifies 
the  data  type  and,  optionally,  some  constraint  of  a  set  of  simple  or  structured  values  which 
are  used  for  representing  the  instances  of  E-class  objects.  The  values  of  a  D-class  are  not 
explicitly  entered  and  stored  in  a  database.  They  are  contained  in  the  instances  of  E-class 
objects.  In  Figure  4.1,  Eid,  E_salary,  and  Works_for  are  class  association  names  which 
connect  the  E-class  Employee  to  D-classes  Integer  and  Salary  and  to  another  E-class 
Company,  respectively.  An  instance  of  Employee  consists  of  an  Eid  value,  an  E_salary 
value,  and  an  instance  reference  (IID)  to  a  company  object.  We  note  that  the  traditional 
concepts  of  "attributes"  and  "entity  associations/relationships"  are  uniformly  represented  in 
structure  by  "associations"  in  ORECOM.  Similarly,  the  relationship  between  a  superclass 
and  a  subclass  recognized  in  object-oriented  models  (the  same  relationship  is  called  a 
generalization  or  categorization  in  some  semantic  models),  say,  between  class  Person  and 
class  Employee,  is  represented  by  a  class  association  linking  Person  to  Employee.  As  we 
pointed  out  before,  the  detailed  semantic  properties  of  different  association  types  such  as 
"attribute,"  "entity  association,"  "superclass/subclass  or  generalization  association"  are 
captured  in  ORECOM  by  micro-rules. 

When  two  object  classes  are  associated  with  each  other  as  defined  in  a  schema,  their 
objects  and  thus  object  instances  may  also  be  associated  with  each  other  through  the  same 
association.  For  example,  the  class  association  "Company  *>Hires  Employee"  implies  that 
there  can  be  an  object  association  "c  *>Hires  e"  for  some  c  in  class  Company  and  some  e 
in  class  Employee. 
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ENTITY-CLASS  Employee 

ASSOCIATIONS 

Eid  :  Integer; 
ESalary :  Salary; 
Worksjor :  Company; 

METHODS 

DisplayData(); 
SetSalary(); 

IMPLEMENTATION 

DisplayData()  is 
begin  end; 

SetSal;ary()  is 
begin  end; 


MICRO-RULES 

rule  Emp001  is 

triggered  before  this.DISASSOCIATE(Works_for,  c:Company) 

condition  

action  

otherwise  

rule  Emp002  is  

END  Employee; 


Figure  4.1.  Example  of  an  entity-class  Employee. 


Based  on  the  primitive  structural  constructs  (objects,  object  associations, 
classes,  and  class  associations)  described  above,  the  modeling  constructs  of  many  high- 
level  data  models  can  be  represented  in  ORECOM's  neutral  representation.  For  example, 
Figure  4.2  shows  the  graphical  representations  of  the  constructs  used  in  EXPRESS,  IDEF- 
IX,  NIAM,  OSAM*,  SDM  [HAM81,  TH089],  and  OMT  [RUM91]  for  modeling  the 
superclass-subclass  relationship  between  Employee  and  Secretary.  Although,  these  data 
models  use  different  terminologies  and  graphical  symbols  to  represent  their  constructs,  the 
underlying  common  structural  properties  can  be  specified  by  the  concepts  of  E-classes 
Employee  and  Secretary  and  their  class  association.  Additional  to  the  structural  primitives, 
a  set  of  semantic  constraints  representing  the  implied  meaning  of  superclass-subclass 
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ORECOM 


OBJECTS 


ENTITY 
CLASS 


Employee 


ASSOCIATION  <^  I 


ENTITY  A  . 

CLASS  \  1 


BASIC 
CZ^CONSTRAINTS 


Secretary 


A  secretary  inherits  all  the^ 
properties  of  an  employee, 
including  attributes, 
operations  and  rules. 

An  employee  may  or 
may  not  be  a  secretary. 

A  secretary  must  also 
be  an  employee. 

There  is  an  1-1 
correspondence  between 
an  employee  and  his/her 
role  as  a  secretary. 


Structure-?-  Behavior 


OPERATIONS  & 
MICRO-RULES 

OPERATIONS  & 
MICRO-RULES 

OPERATIONS  & 
MICRO-RULES 

OPERATIONS  & 
MICRO-RULES 


Figure  4.2.  Semantic  decomposition  of  different  models  to  ORECOM's  neutral 
representation. 


relationship  can  be  explicitly  defined  by  a  set  of  methods  and  micro-rules  which  correspond 
to  the  constraint  statements  shown  in  the  figure  for  capturing  the  behavioral  properties  of 
these  two  classes  and  their  association.  By  translating  high-level  modeling  constructs  into 
ORECOM's  general  structural  primitives  and  detailed  constraint  rules,  subtle  differences 
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among  these  constructs  can  be  uncovered.  For  example,  in  IDEF-1X,  it  is  required  to 
specify  a  discriminator  for  the  superclass-subclass  relationship  between  Employee  and 
Secretary.  The  discriminator  is  one  attribute  of  the  superclass,  whose  value  determines 
which  subclass  a  superclass  object  should  be  a  member  of.  This  requirement  does  not  exist 
in  the  other  models  mentioned  above.  It  can  be  defined  in  terms  of  the  insertion  behavior 
followed  by  a  DBMS. 

4.2  Behavioral  Primitives 

Object  behavior  means  how  an  object  performs  an  operation  (or  a  method)  upon 
other  objects  as  well  as  how  it  reacts  in  response  to  an  operation.  So,  the  behavioral 
semantics  of  an  application  world  can  be  defined  by  operations  that  can  be  performed  on 
objects  and  the  rules  that  these  objects  and  their  operations  have  to  obey.  The  traditional 
data  models  such  as  relational,  network  and  hierarchical  models  provide  only  some 
structural  constructs  and  very  limited  constraint  specification  facilities  (e.g.,  by  keywords 
such  as  Keys,  Non-Null,  domain  constraints,  etc.).  They  do  not  capture  the  behavioral 
properties  of  objects  like  object-oriented  models  do  in  term  of  operarions  or  methods  which 
represent  the  "procedural  semantics"  of  objects.  In  the  traditional  DBMSs,  this  type  of 
semantic  properties  are  either  implemented  in  application  programs  or  hard-coded  in 
DBMSs.  More  recent  data  models  such  as  the  ones  used  in  ODE  [AGR89,  GEH91], 
OSAM*  [SU89],  STARBUST  [LOH91],  POSTGRES  [ST091],  etc.,  provide  high-level 
rule  specification  facilities  for  defining  different  types  of  semantic  constraints.  Thus,  in 
order  to  accommodate  these  existing  data  models  and  their  translations,  a  neutral  data  model 
like  ORECOM  needs  to  provide  the  facilities  for  method  and  rule  specifications.  There  are 
five  primitive  system-defined  object  operations  and  a  rule  specification  language  provided 
in  ORECOM.  They  are  described  in  the  following  sections. 
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4.2.1  Method  Specification 

Like  in  other  object-oriented  data  models,  each  system-predefined  or  user-defined 
object  class  in  ORECOM  may  contain  a  number  of  method  specifications  each  of  which 
defines  the  operation  that  can  be  performed  on  its  objects.  Each  method  specification  has  a 
name,  a  number  of  parameters  associated  with  the  operation  and  optionally  a  returned  value 
(e.g.,  DisplayData  and  SetSalary  in  Figure  4.1).  The  activation  of  an  operation  on  an 
object  is  carried  out  by  message  passing.  Methods  can  be  either  system-defined  or  user- 
defined.  System-defined  methods  are  object  operations  that  are  common  to  all  objects  and 
are  defined  in  some  system-predefined  classes  and  inherited  by  user-defined  classes.  User- 
defined  methods  are  object  operations  that  are  application-specific  and  applicable  only  to  the 
objects  of  user-defined  classes,  in  which  these  operations  are  specified,  and  their 
subclasses.  Corresponding  to  each  method  specification,  there  is  a  method  implementation 
containing  the  program  code  that  carries  out  the  operation. 

Since  user-defined  methods  are  application  dependent  and  the  procedural  semantics 
captured  by  them  are  expressed  by  program  code,  there  is  no  known  method  for  analyzing 
programs  to  capture  the  semantics  of  implemented  algorithms.  In  a  data  model  or  schema 
translation  system,  programs  that  implement  user-defined  methods  have  to  be  converted 
either  manually  or  automatically  to  programs  that  suit  the  target  application  system.  In  this 
work,  we  shall  consider  only  the  system-defined  operations  that  manipulate  a  database.  We 
shall  present  the  system-defined  methods  of  ORECOM  in  the  remainder  of  this  section.  We 
use  the  dot  notation  "x.op"  to  specify  that  the  object  operation  op  is  performed  on  the  object 
x.  There  are  five  system-defined  object  operations  supported  in  ORECOM:  CREATE, 
DESTROY,  ASSOCIATE,  DISASSOCIATE,  and  READ.  These  operations  are 
corresponding  to  the  structural  primitives  of  objects  and  object  associations  discussed 
before.  The  operation  x.CREATE  establishes  the  object  x  in  a  class  where  the  operation  is 
executed.  Its  inverse  operation  x. DESTROY  terminates  the  membership  of  x  in  that 
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class.  For  establishing  an  object  association  between  two  objects  x  and  y,  the  associate 
operation  x.ASSOCIATE(a,  y)  is  used.  Here,  a  specifies  the  name  of  the  association. 
The  inverse  of  ASSOCIATE  is  DISASSOCIATE  as  in  x.DISASSOCIATE(ot,  y).  We 
note  here  that,  since  many  types  of  relationships  found  in  the  existing  data  models  are 
modeled  uniformly  in  ORECOM  as  objects  and  class  associations,  data  manipulation 
operations  such  as  update,  insert,  and  delete  are  modeled  by  ASSOCIATE  and 
DISASSOCIATE  operations  in  ORECOM.  For  example,  updating  an  attribute  value  of  an 
object  can  be  represented  by  disassociating  the  object  with  the  old  value  (a  D-class  object) 
and  associating  the  object  with  the  new  value.  Inserting  an  object  instance  is  represented  by 
creating  the  object  and  associating  the  object  with  a  number  of  D-class  and/or  E-class 
objects  through  different  association  names  (i.e.,  attributes).  The  inverse  operations  can  be 
done  for  the  deletion  operation.  The  last  system-defined  operation,  READ,  which  is 
represented  as  x.a,  is  used  for  specifying  the  retrieval  of  all  objects  that  are  associated  with 
x  through  the  association  a. 

4.2.2  Rule  Specification 

Constraints  captured  by  high-level  data  models  are  used  by  DBMSs  to  control  the 
data  retrieval  and  manipulation  operations  so  that  these  constraints  are  enforced  and  the 
database  integrity  is  maintained.  They  can  be  explicitly  defined  in  terms  of  knowledge  rules 
which  specify  the  operational  behaviors  of  objects  and  their  associations.  In  ORECOM, 
these  knowledge  rules  are  called  "micro-rules"  since  they  are  used  to  specify  the  detailed 
semantic  properties  of  high-level  data  modeling  constructs  and  constraints. 

The  rule  specification  language  used  in  ORECOM  for  defining  micro-rules  is  the 
rule  specification  part  of  a  general-purpose  knowledge  base  programming  language  called 
K  which  has  been  designed  and  implemented  at  the  Database  Systems  Research  and 
Development  Center  of  the  University  of  Florida  [SHY92,  ARR92].  The  language  is  a 
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calculus-based  language  and  has  triggers  and  association  pattern  specification  capabilities. 
The  syntax  of  a  micro-rule  is  given  below: 

rule  rule_id  is 

triggered  trigger_conditions 

[condition  guarded_expression] 

[action  statements] 

[otherwise  statements] 
end  rule_id; 

The  rule_id  is  a  unique  name  for  rule  identification  purpose.  Besides  the  rule_id,  a  rule 
consists  of  a  set  of  trigger_conditions  and  a  rule  body  defined  by  condition,  action,  and 
otherwise  clauses.  When  any  of  the  trigger_conditions  is  satisfied,  the  rule  is  triggered  and 
the  rule  body  is  evaluated.  A  trigger_condition  is  defined  by  a  triggering  time  (i.e.,  before, 
after,  or  immediate_after)  and  a  system-defined  or  user-defined  method.  For  example,  the 
triggering  condition  "after  x.ASSOCIATE(a,  y)"  states  that  after  establishing  an 
association  named  a  between  objects  x  and  y,  the  following  rule  body  should  be  evaluated. 
The  condition  clause  can  be  specified  by  a  guarded  expression  in  the  form  of  "Gl, Gn  I 
T",  where  Gi,  i  =  l..n,  are  the  guards  and  T  is  the  target.  The  G's  and  T  are  Boolean 
expressions  and  may  contain  association  patterns  (to  be  explained  below).  A  guarded 
expression  is  evaluated  to  TRUE,  SKIP,  or  FALSE.  The  value  TRUE  is  returned  if  Gl, 
Gn,  and  T  are  all  true.  In  this  case,  the  statements  specified  in  the  action-clause  will  be 
executed.  If  any  one  of  Gl, Gn  is  false  in  a  sequential  evaluation  of  these  expressions, 
the  guarded_expression  returns  the  value  SKIP,  which  will  cause  the  rest  of  the  rule  body 
to  be  ignored.  If  all  the  guards  are  true  but  the  target  T  is  false,  then  the  expression  returns 
FALSE.  A  false  result  will  cause  the  statements  specified  in  the  otherwise-clause  to  be 
executed.  The  guarded  expression  is  a  short  hand  for  a  complex  expression  that  involves 
the  nesting  of  many  condition-action-otherwise  sub-expressions.  The  statements  in  both 
action-clause  and  otherwise -clause  can  be  expressions  of  various  kinds  including  system 
and  user-defined  methods  or  any  K's  computation  statements  including  assignments, 
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quantified  expressions,  conditional  statements,  repetitive  statements,  and  so  on.  [SHY91, 
92]. 

Besides  the  usual  predicates  used  in  Boolean  expressions,  the  rule  specification 
language  of  ORECOM  allows  "patterns  of  object  associations"  or  simply  "association 
patterns"  to  be  specified  in  the  condition  clause.  For  example,  the  expression  "x:X[P\]"  is 
a  simple  pattern  which  specifies  that  all  objects  of  class  X  which  satisfy  the  predicate 
expression  Px  can  be  referenced  by  the  object  variable  x.  Thus,  the  expression 
"e:Employee[Age  >  50  AND  Salary  =  70K]"  would  identifies  all  Employee  objects  whose 
age  is  greater  than  50  and  whose  salary  is  equal  to  70K.  The  variable  e  ranges  over  this  set 
of  employee  objects.  A  more  complex  association  pattern  may  involve  two  classes  in  the 
form  of  (x:X  *>a  y:Y)  or  (x:X  !>a  y:Y).  (Here,  predicates  Px  and  Py  associated  with 
classes  X  and  Y  are  omitted  to  keep  the  expressions  simpler.)  The  pattern  (x:X  *>a  y:Y) 
returns  all  pairs  of  X  and  Y  objects  which  are  associated  (as  specified  by  the  association 
operator  '*')  through  a,  whereas  the  pattern  (x:X  !>oc  y:Y)  returns  all  X  objects  which  are 
not  associated  (as  specified  by  the  non-association  operator  "!')  with  any  Y  objects  through 
a  and  all  Y  objects  which  are  not  associated  with  any  X  objects  through  the  same 
association.  The  object  variables  x  and  y  are  used  to  reference  the  objects  that  satisfy  the 
expressions.  As  discussed  before,  the  direction  symbols,  ">"  and  "<",  distinguish  the 
subject/agent  from  the  object  of  an  association  and  the  following  conditions  hold: 

"x:X  *>ct  y:Y"  =  "x:X  *<a  l  y:Y"  and 
"x:X  !>ay:Y"  =  "x:X  !<a-i  y:Y" 

where  or1  is  the  inverse  association  of  a. 

Association  patterns  may  involve  a  long  linear  structure  of  object  classes.  They  may 
also  contain  AND/OR  branches  and  loops.  They  provide  a  simpler  way  of  specifying 
complex  associations  among  object  classes  and  thus  their  objects.  We  shall  explain  the 
branching  structures:  "x:X  AND(L1  PI,  L2  P2,       Ln  Pn)"  and  "x:X  OR(Ll 
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PI,  L2  P2, Ln  Pn)".  The  Li  in  these  expressions  specifies  an  association  link  such 
as  "*>cci"  or  "!<cu"  and  'Pi'  represents  a  linear  tree  or  network  structured  association 
pattern,  i  =  l..n.  In  a  branching  association  pattern  with  a  logical  "AND",  the  set  of  objects 
returned  from  class  X  must  associate  or  not  associate  (depending  on  each  Li  specification) 
with  every  pattern  of  Pi,  i  =  l..n.  In  a  branching  association  pattern  with  logical  "OR", 
those  returned  X  objects  must  associate  (or  not  associate)  with  at  least  one  pattern  of  Pi,  i  = 
l..n. 

The  syntax  and  semantics  of  micro-rules  and  the  association  patterns  explained 
above  provide  a  powerful  means  for  specifying  a  variety  of  semantic  constraints  found  in 
the  existing  data  models.  We  have  used  such  a  rule  specification  language  to  define  all  the 
constructs  and  constraints  of  several  semantically  rich  data  models  such  as  EXPRESS, 
IDEF-1X,  NIAM,  and  OSAM*. 


CHAPTER  5 

THE  GENERAL  CONSTRAINT  TYPES  (MACROS) 


In  this  chapter,  we  shall  present  a  number  of  semantic  constraint  types  commonly 
found  in  the  existing  modeling  constructs.  They  are  the  results  of  analyzing  and  relating  the 
constructs  and  constraints  of  a  number  of  semantically  rich  data  models.  For  each 
constraint  type,  we  introduce  a  "macro"  representation,  which  is  a  parameterized  way  of 
specifying  the  constraint  type  and  its  variations.  Corresponding  to  each  variation,  a  set  of 
micro-rules  can  be  defined  to  specify  its  detailed  operational  semantics.  Thus,  a  variation  of 
a  macro  is  an  abstraction  of  a  set  of  detailed  micro-rules.  The  macro  representation  is 
particularly  suitable  for  the  comparison  and  conversion  of  modeling  constructs  and 
constraints  since  it  is  a  more  compact  representation  than  the  micro-rule  representation.  The 
former  can  be  used  by  a  data  model  and  schema  translation  system  to  compare  the 
ORECOM  representations  of  modeling  constructs  and  constraints  and  the  latter  can  be  used 
by  the  system  to  generate  explanations  or  program  code  to  account  for  the  discrepancies 
found  in  a  translation. 

Our  analysis  of  the  modeling  constructs  and  constraints  of  data  models  follows  the 
following  approach.  We  first  determine  what  are  the  constraint  types  and  their  variations 
that  are  meaningful  to  a  set  of  objects  in  an  object  class  (i.e.,  intra-class  constraints). 
We  then  examine  the  possible  constraint  types  and  variations  that  are  meaningful  to  the 
association  of  two  object  classes  (i.e.,  the  semantics  of  a  binary  association  or  inter-class 
constraints).  Lastly,  we  examine  those  constraint  types  and  variations  related  to  an  object 
class  and  its  multiple  associations  with  other  object  classes  (i.e.,  the  semantic  of  n-nary 
associations  or  inter-association  constraints).  This  approach  provides  a  systematic 
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way  of  determining  the  semantic  properties  that  can  exist  in  the  structural  primitives  of 
ORECOM. 

In  the  following  sections,  there  are  eight  general  constraint  types  or  macros  to  be 
discussed,  each  with  its  syntax  definition,  semantic  description,  part  of  its  corresponding 
micro-rule  representation,  and  some  examples  to  illustrate  its  uses.  The  complete  micro-rule 
representation  of  each  macro  is  given  in  the  APPENDIX  A  of  this  dissertation. 

5.1  Intra-class  Constraints 

In  spite  of  the  differences  in  terminologies  and  notations,  all  existing  data  models 
provide  some  ways  of  specifying  the  structures  (or  data  types)  of  a  set  of  objects  that  form 
a  class  (or  its  equivalent  concepts),  the  ways  objects  can  be  individually  identified,  the 
constraints  associated  with  the  membership  of  objects  in  the  class.  Figure  5.1  provides 
some  examples.  In  the  IDEF-1X  notation  shown  in  5.1(a),  Eid  and  Ename  are  used 


IDEF-1X 


EXPRESS 


OSAM* 


NIAM 


Employee 


Eid 
Ename 


(a) 


TYPE 

Positive  =  INTEGER; 

WHERE 
SELF>0; 
END_TYPE; 

(b) 


Company 


ProjTeam 


SET[5,20] 


Employee 


(c) 


i  Date 


(d) 


Figure  5.1.  Examples  of  modeling  constructs  that  contain  intra-class  constraints. 


together  as  a  required  external  identifier  (or  primary  key)  of  Employee  objects.  In  5.1(b), 
the  data  type  Positive  defined  in  EXPRESS  allows  only  positive  non-zero  integers  to  be  its 
members.  Figure  5.1(c)  shows  that  the  attribute  ProjTeam  of  the  entity  class  Company  in 
OSAM*  is  defined  over  the  domain  class  EmpSet  having  a  constraint  of  five  to  twenty 
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employee  instances  which  in  turn  is  defined  over  the  class  Employee.  In  Figure  5.1(d), 
each  member  of  the  NIAM's  so-called  lexical  object  type  (LOT)  Date  is  assumed  to 
represent  a  tuple  of  objects  from  other  LOTs  Month,  Day,  and  Year. 

In  ORECOM,  we  introduce  a  constraint  type  or  macro  called  MEMBERSHIP 
(MB),  which  has  the  following  syntax  (a  parameterized  notation)  and  semantics  (in  the 
form  of  a  micro- rule): 

Macro  MB  (X,  O,  I,  S,  T,  C,  M)  (Ml.l) 
Micro-rule 

rule  MB-01  is     /*  defined  in  the  meta-class  named  CLASS  whose  instances  are 

definitions  of  all  classes  defined  in  a  system  */ 
triggered     immediate_after  this.CREATE 
action        this.ClassName  :=  X; 

this.ObjectType  :=  O; 

if  O  =  "system-named"  then  this.Identifier  :=  I; 

else  this.Identifier  :=  ""; 
end_if; 

this.Structure  :=  S; 
this.ClassType  =  T; 
this. Constraint  :=  C; 
this.LocalOperation  :=  M; 

The  above  MB  macro  specifies  properties  and  constraints  of  an  object  class  that 
must  be  satisfied  by  its  members.  These  properties  and  constraints  are  specified  by  a  class 
name  (X),  an  object  type  (O)  which  takes  the  value  of  "self-naming"  or  "system-named",  a 
user-defined  object  identifier  (I)  (i.e.,  attribute(s)  that  serves  as  a  primary  key)  if  the  object 
type  is  system-named,  an  object  structure  (S)  which  specifies  the  structure  of  its  members 
(simple  or  complex  structures  such  as  SET,  LIST,  BAG,  ARRAY,  TUPLE,  etc.),  a  class 
type  (T)  which  is  either  an  E-class  or  a  D-class,  a  set  of  membership  constraints  (C)  which 
either  list  the  possible  members,  or  specify  the  range  of  values  that  constrain  its  members, 
or  express  in  logical  expressions  that  evaluate  to  true  or  false,  and  a  set  of  methods  (M) 
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which  specify  the  meaningful  operations  that  can  be  performed  on  the  class  members.  A 
type  definition  in  a  high-level  data  model  can  be  mapped  into  the  MB  macro  with  specific 
values  assigned  to  its  parameters.  For  example,  the  macro  representations  of  the  four 
classes  shown  in  Figure  5.1  are  as  follows: 

MB(Employee,  system-named,  (Eid,  Ename),  simple,  E-CLASS,  -,  - ) 
MB  (Positive,  self-naming,  -,  simple,  Integer,  Positive  >  0,  - ) 
MB(EmpSet,  self-naming,  -,  SET,  Employee,  -,  - ) 
MB(Date,  self-naming,  -,  TUPLE,  (Month,  Day,  Year),  -,  - ) 

The  "-"  sign  in  the  above  macros  indicates  that  a  parameter  is  not  specified  in  the  original 
construct,  and  the  "E-CLASS"  of  the  first  macro  is  a  system-defined  class  which  contains 
all  defined  entity  classes.  By  translating  the  constructs  of  different  data  models  which 
capture  the  concept  and  constraints  of  MEMBERSHIP  into  the  above  macro  representations 
and  comparing  their  parameter  values,  a  schema  translation  system  will  be  able  to  identify 
their  semantic  similarities  and  differences. 

The  system-defined  meta-class  CLASS  is  a  class  containing  all  definitions  of 
classes  in  terms  of  the  following  seven  attributes:  ClassName,  ObjectType,  Identifier, 
Structure,  ClassType,  Constraint,  and  LocalOperation.  The  micro-rule  MB-01  shown 
above  simply  sets  the  attribute  values  for  a  class,  which  are  specified  in  a  MB  macro,  after 
the  class  is  created  as  an  object  instance  (identified  by  "this")  in  the  class  CLASS. 

5.2  Inter-Class  and  Inter- Association  Constraints 

We  now  examine  some  of  the  constraint  types,  which  are  commonly  seen  in  the 
existing  data  models,  for  restricting  an  association  between  two  object  classes  (inter-class 
constraints)  and  gmultiple  associations  of  an  object  class  (inter-association  constraints). 
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5.2.1  PARTICIPATION  (PT^ 

As  an  inter-class  constraint,  this  constraint  type  restricts  the  total  number  of  objects 
of  one  class  that  must  participate  in  an  association  with  the  objects  of  another  class.  It  is  a 
very  general  constraint  type  which  can  be  used  as  a  common  representation  of  a  number  of 
constraints  used  in  different  data  models.  Figure  5.2  shows  some  schema  examples  taken 
from  different  data  models.  The  alternate  key,  SSN,  of  Employee  entity  in  the  IDEF-1X 


S1  (IDEF-1X) 


S2  (EXPRESS) 


S3  (SDM) 


Employee 


ENTITY  Company; 
Fax :  OPTIONAL 

INTEGER; 
Phone:  OPTIONAL 
INTEGER; 


WHERE 

Fax  <  9999999999; 

Fax  <>  Phone; 
END  ENTITY; 


CLASS  Engineer 

( 

Position  :  INTEGER, 

INITIALVALUE  10; 
Salary :  REAL, 

DERIVED  BY 
Position  *  325.3  +  20000; 


); 


S4  (OSAM') 


S5  (NIAM) 


S6  (OMT) 


Student 


Full_Time_ 
Student 


Part_Time_ 
Student 


Car 

IF 


Engine 

Body 

Wheels 

Figure  5.2.  Examples  of  schemata  of  different  data  models. 


schema  S 1  is  a  non-null  attribute.  It  requires  that  every  Employee  entity  must  be  associated 
with  a  social  security  number.  In  other  words,  there  is  a  total  participation  constraint 
associated  with  the  Employees'  associations  with  social  security  numbers.  In  the  schema 
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S2  defined  in  EXPRESS,  both  Fax  and  Phone  are  optional  attributes.  In  ORECOM's 
representation,  this  is  a  partial  participation  constraint  associated  with  the  Company  class's 
associations  with  Fax  class  and  Phone  class  since  company  objects  may,  but  do  not  have  to 
have  Fax  and  Phone  numbers.  In  the  SDM  model,  an  attribute  can  have  an  initial  value 
assigned  to  it.  The  schema  S3  shows  that  the  initial  value  for  the  Position  of  each  Engineer 
object  is  '10'.  This  default  attribute  value  assignment  implies  the  constraint  of  total 
participation  since  an  engineer  will  have  a  position  value  equal  to  either  10  or  some  other 
number  but  not  null.  The  schema  S4  shows  an  interaction  association  (I)  defined  in  the 
OSAM*  model  to  capture  the  semantics  that  each  Works_for  object  represents  the  fact  that 
an  Employee  object  is  associated  with  a  Project  object  and  the  association  is  itself  modeled 
as  an  object.  The  construct,  among  other  semantic  properties,  has  a  total  participation 
constraint,  namely  all  Works_for  objects  have  to  be  associated  with  some  Employee  objects 
as  well  as  with  some  Project  objects.  Existence  dependency  is  another  frequently  used 
inter-class  constraint,  which  is  available  in  both  the  NIAM  schema  S5  and  the  OMT  schema 
S6  in  Figure  5.2.  In  S5,  every  Full_Time_Student  object  and  every  Part_Time_Student 
object  must  also  be  a  Student  object,  that  is,  they  are  all  "existence  dependent"  on  the 
Student  objects.  From  ORECOM's  point  of  view,  both  Full_Time_Student  and 
Part_Time_Student  classes  are  totally  participated  in  their  associations  with  the  Student 
class.  (The  symbol  "T"  in  S5  specifies  a  total  specialization  which  means  that  a  student 
object  must  be  in  either  Full_Time_Student  class  or  Part_Time_Student  class.  This  total 
specialization  is  an  example  of  an  inter-association  constraint  of  the  PARTICIPATION 
constraint  type  which  will  be  described  later.  The  other  symbol  "X"  in  S5  specifies  a  set 
exclusive  constraint  which  means  that  an  object  in  Full_Time_Student  class  can  not  be  in 
Part_Time_Student  class  and  vice  versa.  The  set  exclusive  constraint  belongs  to  another 
inter-association  constraint  type  called  Logical-Dependence  which  will  be  addressed  in 
Section  5.2.7.)  The  Car  class  in  S6  is  an  aggregation  of  classes  Engine,  Body,  and 
Wheels,  and  according  to  the  semantics  of  aggregation  defined  in  the  OMT  model 


37 


[RUM91],  a  Car  object  can  not  exist  if  any  of  its  aggregation  components  (i.e.,  an  Engine 
object,  a  Body  object,  and  a  Wheels  object)  does  not  exist.  In  this  case,  there  are  three  total 
participation  constraints  on  the  Car  class,  one  for  each  of  these  three  associations.  On  the 
other  hand,  not  every  Engine  (or  Body,  or  Wheels)  object  is  used  in  a  car,  that  is,  there  is 
only  a  partial  participation  constraint  associated  with  Engine's  (or  Body's,  or  Wheels') 
association  with  Car.  The  above  examples  clearly  show  that  the  modeling  constructs  of 
different  data  models  may  look  very  different.  However,  if  their  semantics  are  decomposed 
into  more  primitive  representations,  part  of  their  semantics  may  overlap  and  can  be 
explicitly  identified  (in  the  above  examples,  the  common  semantics  are  the  variations  of  the 
PARTICIPATION  constraint  type). 

We  shall  now  consider  the  more  general  representation  of  the  PARTICIPATION 
constraint  type  and  its  macro  and  micro-rule  representations. 

Macro:  PT  (X,  min,  max,  a,  Y)  (M2.1) 
Micro: 

Rule  PT-01  is    /*  defined  in  class  X  */ 

triggered   after  this.CREATE,  immediate_after  this.DISASSOCIATE  (a,y) 
condition  exist  x  in  ( x:X  *>a  Y  where  Count(x)  <  min  ) 
action  REJECT; 

Rule  PT-02  is     /*  defined  in  class  X  */ 
triggered   immediate_after  this. ASSOCIATE  (a,y) 
condition    exist  x  in  ( x:X  *>a  Y  where  Count(x)  >  max  ) 
action  REJECT; 

The  inter-class  PARTICIPATION  (PT)  macro  uses  two  parameters,  min  and  max, 
to  specify  a  lower-bound  and  an  upper-bound  of  the  number  of  X  objects  which  participate 
in  the  association  named  a  with  the  class  Y.  The  values  of  min  and  max  can  be  zero,  a 
positive  integer,  or  any  expression  that  returns  a  positive  integer.  The  min  value  is  always 
less  than  the  max  value.  If  min  equals  to  zero,  it  means  that  there  is  no  constraint  on  the 
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lower-bound.  If  it  equals  to  the  expression  "Count(X)",  which  returns  the  current  total 
number  of  objects  in  class  X,  then  a  total  participation  constraint  is  specified.  On  the  other 
hand,  if  max  equals  to  zero,  it  means  that  no  object  can  participate  in  the  association.  Max 
equals  to  "Count(X)"  simply  means  that  all  X  objects  can  participate.  As  an  example,  the 
macro  "PT  (Employee,  5,  Count(Employee),  SSN,  Integer)"  specifies  that  at  least  five 
employees  must  have  social  security  numbers,  whereas  the  macro  "PT  (Employee, 
Count(Employee),  Count(Employee),  SSN,  Integer)"  specifies  a  total  participation  which 
states  that  every  employee  must  have  a  social  security  number. 

Using  the  macro  defined  in  (M2.1),  the  macro  representations  of  some  variations  of 
the  PARTICIPATION  constraint  type  which  exist  in  the  modeling  constructs  of  Figure  5.2 
are  shown  below: 


SI:  PT(Employee,  Count(Employee),  Count(Employee),  SSN,  Integer) 

—  a  non-null  attribute 

PT(Integer,  0,  Count(Integer),  SSN"1,  Employee) 

—  a  partial  participation 

S2:  PT(Company,  0,  Count(Company),  Fax,  Integer) 

—  an  optional  attribute 

S3:  PT(Engineer,  Count(Engineer),  Count(Engineer),  Position,  Integer) 

—  a  default  attribute  value  which  implies  a  non-null  constraint 

S4:  PT(Works_for,  Count(Works_for),  Count(Works_for),  -,  Employee) 

—  an  implied  total  participation 

S5:  PT(Full_Time_Student,  Count(Full_Time_Student),  Count(Full_Time_Student),  -, 
Student) 

PT(Part_Time_Student,  Count(Part_Time_Student),  Count(Part_Time_Student),  -, 
Student) 

—  existence  dependencies 

S6:  PT(Car,  Count(Car),  Count(Car),  -,  Engine) 

—  an  existence  dependency 
PT(Engine,  0,  Count(Engine),  -,  Car) 

—  a  partial  participation 


The  micro-rule  PT-01  is  an  example  operational  rule  which  can  be  defined  in  class 
X  to  enforce  the  participation  constraint  of  X  objects.  It  specifies  the  enforcement  of  the 
constraint  after  a  CREATE  transaction  has  been  performed  on  X  or  after  a 
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DISASSOCIATE  operation  is  executed  on  an  object  of  X  identified  by  "this"  and  an  object 
of  Y  identified  by  "y".  The  function  "Count(x)"  returns  the  number  of  those  X  objects 
which  fall  in  the  association  pattern  "x:X  *>cc  Y".  This  value  is  compared  with  the  min 
value.  Here,  x  is  an  object  variable  which  ranges  over  those  X  objects  that  satisfy  the 
pattern.  "After"  means  that  the  rule  is  verified  after  the  CREATE  transaction  instead  of  right 
after  the  CREATE  operation  which  is  specified  using  the  key-word  "immediate_after".  In 
the  CREATE  transaction,  the  association  between  the  created  X  object  and  some  Y 
object(s)  can  be  established.  If  the  minimum  participation  constraint  is  violated  after  the 
creation  transaction  or  after  the  disassociation  operation,  the  operation  will  be  rejected.  The 
rejection  of  the  creation  transaction  will  cause  the  transaction  to  be  rolled  back  and  the 
rejection  of  the  disassociation  operation  will  cause  it  to  be  aborted.  The  rule  PT-02  ensures 
that  the  upper-bound  max  is  not  violated  by  an  ASSOCIATE  operation  by  comparing  it 
with  the  current  number  of  the  participating  X  objects  (i.e.,  Count(x)). 

Sometimes  it  is  desired  that  a  participation  constraint  applies  only  to  a  subset  of 
objects  of  a  class  rather  than  the  entire  set  of  objects  as  in  the  examples  shown  above.  For 
instance,  in  OSAM*,  a  user-defined  constraint  can  be  stated  as  a  rule  inside  the  Employee 
class  such  as  "all  employees  who  have  no  Eids  must  have  SSNs".  This  is  a  total 
participation  constraint  for  only  a  subset  of  employees  rather  than  all  employees.  The 
condition  that  all  employees  who  have  no  Eids  is  called  a  selection  condition  of  the 
Employee  class.  The  incorporation  of  a  selection  condition  to  each  class  specified  in  the 
participation  macro  makes  it  even  more  general  and  useful  for  capturing  some  user-defined 
constraints.  For  this  reason,  we  extend  the  participation  macro  M2.1  into  the  following 
form: 


Macro:  PT  (X,  Px,  min,  max,  a,  Y,  PY) 


(M2.2) 
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The  semantics  of  this  macro  then  becomes  that  at  least  min  and  at  most  max  X  objects 
which  satisfy  the  selection  condition  Px  must  participate  in  the  association  named  a  with 
those  Y  objects  which  satisfy  the  selection  condition  Py.  The  macro  defined  in  M2. 1  can  be 
viewed  as  a  special  case  of  M2.2  with  both  selection  conditions  omitted.  Using  M2.2,  the 
above  OSAM*  example  can  be  represented  as  "PT(Employee,  Employee. Eid  =  nil, 
Count(Employee),  Count(Employee),  SSN,  Integer,  -  )"  where  no  selection  condition  is 
specified  for  the  Integer  class.  Accordingly,  micro-rules  PT-01  and  PT-02  can  be  modified 
to  include  the  expressions  Px  and  Py-  Additional  rules  must  also  be  introduced  to  account 
for  those  operations  that  may  change  the  qualification  of  some  X  or  Y  objects  with  respect 
to  Px  and  Py. 

A  participation  constraint  can  also  exist  in  a  class  which  has  multiple  associations 
with  other  classes.  For  example,  as  shown  in  the  NIAM  schema  S5  of  Figure  5.2,  Student 
class  has  a  total  specialization  constraint  (identified  by  the  symbol  "T")  in  its  associations 
with  Full_Time_Student  and  Part_Time_Student  classes,  meaning  that  every  student  must 
be  in  either  one  of  the  subclasses.  Or,  in  terms  of  the  participation  concept,  Student  objects 
must  be  totally  participated  in  some  associations  with  some  objects  of  these  two  subclasses 
(or  any  number  of  subclasses  in  a  more  general  case).  Thus,  the  PARTICIPATION  macro 
is  further  generalized  in  the  following  form: 

Macro:  PT  (X,  Px,  min,  max,  ((ocl,  Yl,  PY1),       (an,  Yn,  PYn)))  (M2.3) 

This  macro  states  that  the  participation  of  those  X  objects  that  satisfy  Px  and  are  in  the 
associations  ocl,  oc2, an  with  those  Yl,  Y2,  Yn  objects  that  satisfy  PYi,  PY2, 
PYn,  respectively,  must  be  within  the  range  of  [min,  max].  It  is  of  no  importance  which 
association  and  how  many  associations  a  qualified  X  object  actually  participates  in.  Using 
the  macro  M2.3,  the  total  specialization  constraint  of  the  NIAM  schema  S5  can  be 
represented  in  ORECOM  by  "PT  (Student,  -,  Count(Student),  Count(Student),  ((-, 
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Full_Time_Student,  -),  (-,  Part_Time_Student,  -)))",  in  which  no  selection  conditions  are 
specified  for  the  three  classes  in  this  example.  The  corresponding  micro-rule  representation 
of  the  generalized  PT  macro  is  available  in  the  APPENDIX  A.2  of  this  dissertation. 

5.2.2  CARDINALITY  (CD) 

The  CARDINALITY  constraint  type  specifies  that  the  number  of  objects  of  one 
class  which  can  be  associated  with  an  object  of  another  class  must  be  withg47 

in  a  specified  range.  It  is  a  general  constraint  type  that  can  exist  in  an  association 
between  two  classes  as  well  as  among  associations  of  multiple  classes.  In  the  inter-class 
case,  a  cardinality  constraint  is  commonly  expressed  as  follows: 

X  :  Y  =  [minX,  maxX]  :  [minY  :  maxY] 

This  expression  means  that  an  X  object  can  associate  with  a  minimum  number  of  Y  objects 
specified  by  minY  and  a  maximum  number  of  Y  objects  specified  by  maxY,  and  that  a  Y 
object  can  be  associated  with  a  minimum  number  of  X  objects  specified  by  minX  and  a 
maximum  number  of  X  objects  specified  by  maxX.  Using  this  format,  we  can  define  some 
cardinality  constraints  for  the  schemata  given  in  Figure  5.2  as  below  (the  Ms  in  the 
expressions  mean  "many"): 

SI:  Employee  :  SSN  =  [1,1] :  [1,1]  -  employee's  SSN  is  single-valued  and  unique 
S2:  Company  :  Fax    =  [1,M]  :  [1,1]  -  company's  FAX  is  single-valued  and  non-unique 
S3:  Engineer  :  Salary  =  [1,M]  :  [1,1]  -  engineer's  salary  is  single-valued  and  non-unique 

S4:  Employee  :  Works_for  =  [  1 , 1  ]  :  [  1  ,M]  -  each  Works_for  object  involves  one 

employee  but  more  than  one  Works_for 
object  can  be  associated  with  an  employee 

S5:  Student :  Full_Time_Student  =  [1,1]  :  [1,1]  -  a  student  can  only  have  one 

representation  as  a  full  time  student 
and  vice  versa. 

S6:  Car :  Engine  =  [1,1] :  [1,1]  -  one  car,  one  engine  and  vice  versa 
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The  general  representation  of  the  inter-class  CARDINALITY  constraint  type  is 
defined  by  the  following  macro  and  micro-rules. 


Macro:  CD  (X,  a,  Y,  minX,  maxX,  minY,  maxY)  (M3.1) 
Micro: 

Rule  CD-01  is    /*  defined  in  class  X  */ 

triggered   before  this.DISASSOCIATE(a,  y) 

condition  exist  y'  in  ( this  *>a  y':Y  where  Count(y')  =  minY  ) 

action  REJECT 

Rule  CD-02  is    /*  defined  in  class  X  */ 

triggered    before  this.ASSOCIATE(a,  y) 

condition  exist  y'  in  ( this  *>a  y':Y  where  Count(y')  =  maxY ) 

action  REJECT 

Rule  CD-03  is    /*  defined  in  class  Y  */ 

triggered    before  this.DISASSOCIATECct1,  x) 

condition  exist  x'  in  ( this  *<a  x':X  where  Count(x')  =  minX  ) 

action  REJECT 

Rule  CD-04  is    /*  defined  in  class  Y  */ 

triggered   before  this.ASSOCIATE(a-1,  x) 

condition  exist  x'  in  ( this  *<a  x':X  where  Count(x')  =  maxX  ) 

action  REJECT 


The  values  of  the  four  parameters  in  the  CD  macro,  i.e.,  minX,  maxX,  minY,  and 
maxY,  can  be  any  positive  integers  or  the  special  character  'M'.  For  example,  the  value  [1, 
M]  of  [minY,  maxY]  means  that  an  X  object  can  associate  with  many  Y  objects,  whereas 
the  value  [3,  M]  limits  the  minimum  number  of  Y  objects  that  can  be  associated  with  an  X 
object  to  three.  In  the  latter  case,  the  non-zero  minY  does  not  imply  that  every  X  object 
must  be  associated  with  some  Y  object.  But,  if  an  X  object  is  associated  with  some  Y 
object,  it  must  also  be  associated  with  two  other  Y  objects  to  satisfy  the  minimum 
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cardinality  constraint.  Using  M3.1,  the  cardinality  constraints  of  the  above  examples  can  be 
represented  in  the  neutral  macro  forms: 

SI:  CD(Employee,  SSN,  Integer,  1,  1, 1,  1) 

S2:  CD(Company,  Fax,  Integer,  1,  M,  1,  1) 

S3:  CD(Engineer,  Salary,  Real,  1,  M,  1,  1) 

S4:  CD(Employee,  -,  Works_for,  1,  1,  1,  M) 

S5:  CD(Student,  -,  Full_Time_Student,  1,1,1,1) 

S6:  CD(Car,  -,  Engine,  1,1,1,1) 

To  enforce  the  cardinality  constraint  specified  in  a  CD  macro,  four  micro-rules 
named  CD-01,  CD-02,  CD-03,  and  CD-04  are  defined  as  shown  above  to  maintain  the  four 
bounds.  The  lower-bound  minY  can  be  violated  only  by  a  DISASSOCIATE  operation 
which  removes  the  association  of  an  X  object  with  a  Y  object  and  hence  may  decrease  the 
number  of  the  associated  Y  objects  to  a  value  less  than  minY.  Rule  CD-01  checks  if  the 
number  of  Y  objects  associated  with  the  X  object  is  already  equal  to  minY.  If  so,  the 
disassociation  operation  is  rejected.  In  this  rule,  the  function  Count(y')  gives  the  total 
number  of  Y  objects  that  satisfy  the  pattern  "this  *>a  y':Y",  where  'this'  names  the  X 
object  operated  on  by  the  triggering  DISASSOCIATE  operation.  The  interpretations  of  CD- 
02,  CD-03,  and  CD-04  are  similar  to  CD-01 . 

Similar  to  the  extension  of  the  PARTICIPATION  macro,  the  CD  macro  in  M3.1 
can  be  extended  as  below  by  incorporating  selection  conditions  to  allow  a  cardinality 
constraint  to  be  applied  on  selected  subsets  of  objects. 

Macro:   CD  (X,  Px,  a,  Y,  PY,  minX,  maxX,  minY,  maxY)  (M3.2) 

The  advantage  of  using  selection  conditions  in  a  CD  macro  is  that  user-defined  cardinality 
constraints  can  be  captured  by  these  selection  conditions.  Constraints  of  this  type  are 
usually  expressed  using  a  constraint  language  or  implemented  in  an  application  program. 
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For  example,  the  following  cardinality  constraint  can  be  expressed  in  different  ways  using 
different  constraint  specification  languages  or  can  be  implemented  differently  by  different 
application  programs. 

"If  an  employee's  Eid  is  less  than  999,  then  he  or  she  can  associate  with 
at  most  three  Works_for  objects  whose  job  type  is  'type-A'." 

However,  they  can  all  be  translated  into  the  following  macro  representation. 

"CD(Employee,  Employee.Eid  <  999,  -,  Works_for, 
Works_for.JobType  =  'type-A',  1,1,1,  3)" 

We  note  here  that  the  micro-rules  CD-01  to  CD-04  can  be  extended  to  incorporate  Px  and 
Py  and  additional  micro-rules  need  to  be  added  so  that  violations  caused  by  operations  that 
involve  Px  and  Py  can  be  checked.  For  example,  two  more  micro-rules  are  needed  in  the 
last  example  to  check  the  [1,1]:[1,3]  cardinality  whenever  an  employee's  Eid  is  changed 
and  whenever  the  job  type  value  of  a  Works_for  object  is  updated. 

In  the  above,  we  have  presented  a  CD  macro  and  micro-rules  for  representing  a 
cardinality  constraint  on  a  single  association  between  two  classes  (i.e.,  an  inter-class 
cardinality  constraint).  The  same  constraint  type  may  exist  among  multiple  associations  of  a 
class.  We  shall  use  the  SDM  schema  S3  of  Figure  5.2  as  an  example.  In  that  schema,  an 
additional  cardinality  constraint  may  state  that  a  pair  of  Position  and  Salary  values  may  be 
associated  with  a  minimum  of  one  and  a  maximum  of  six  Engineer  objects.  Here,  the 
cardinality  constraint  is  added  between  the  Engineer  class  and  the  pair  of  Integer  and  Real 
classes  through  the  two  associations  Position  and  Salary.  In  the  following,  we  shall 
introduce  two  generalized  CD  macros  for  two  cases  of  inter-association  cardinality 
constraints.  The  first  one  is  a  macro  for  the  cardinality  constraint  between  one  class  and  a 
set  of  directly  associated  classes  as  shown  in  Figure  5.3(a),  and  the  second  one  is  for  the 
cardinality  constraint  between  two  indirectly  associated  sets  of  classes  as  shown  in  Figure 
5.3(b). 
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Figure  5.3.  Two  inter-association  cardinality  constraints: 

(a)  X  :  (Yl, Yn)  =  [minX,  maxX]  :  [minY,  maxY] 

(b)  (Zl, Zm) :  (Yl, Yn)  =  [minZ,  maxZ]  :  [minY,  maxY] 


The  macro  representation  of  the  first  case  is  given  as  M3.3  below.  This  macro 
specifies  two  bounds,  minY  and  maxY,  which  stand  for  the  minimum  and  maximum 
numbers  of  tuples  of  qualified  Yl,  Y2,  Yn  objects  that  a  qualified  X  object  can  be 
associated  with  (through  the  associations  ocl,  a2,  and  an,  respectively).  It  also 
specifies  the  minimum  and  maximum  numbers  of  qualified  X  objects  with  which  a  tuple  of 
qualified  Yl,  Y2,  ....  and  Yn  objects  can  be  associated  with  through  the  associations  ccH, 
a2"1, and  an1,  respectively. 

Macro: 

CD  (X,  Px,  ((ocl,  Yl,  PYi),      (an,  Yn,  PY„)),  minX,  maxX,  minY, 

maxY)  (M3.3) 

Using  M3.3,  our  previous  example  of  inter-association  cardinality  constraint  can  be 
represented  as  "CD(Engineer,  -,  ((Position,  Integer,  -),  (Salary,  Real,  -)),  1,  6,  1,  1)"  with 
no  selection  conditions  specified. 

The  micro-rule  representation  of  M3.3  is  basically  the  same  as  that  of  M3.2  except 
that  additional  rules  of  the  forms  similar  to  CD-03  and  CD-04  are  needed  because  of  the 
multiple  classes  Yl,  Y2,      and  Yn,  and  the  Count  function  of  CD-01  and  CD-02  is 
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extended  to  count  the  number  of  associated  tuples  of  Yl  ...  Yn  objects  associated  with  an 
X  object. 

The  second  case  of  a  cardinality  constraint  is  illustrated  in  Figure  5.3(b),  where  two 
sets  of  classes,  (Zl,  Zm)  and  (Yl,  Yn),  are  indirectly  associated  through  another 
set  of  classes  (XI,  Xk).  A  cardinality  constraint  can  be  specified  for  the  two  sets  of 
associations  or  attributes,  ((31, (3m)  and  (ccl, an),  such  that 

(Zl,...,  Zm)  :  (Yl,...,  Yn)  =  [minZ,  maxZ]  :  [minY,  maxY]. 

The  macro  that  represents  such  an  inter-association  cardinality  constraint  is  defined  as 
follows: 

Macro: 

CD  ((((31,Z1,PZ1),      (pm,Zm,PZm)),  ((Xl,PXi),  (Xk,PXk)), 

((oc1,Y1,Pyi),      (an,Yn,PYn))>  minZ,  maxZ,  minY,  maxY)  (M3.4) 

This  macro  is  the  most  general  form  of  all  cardinality  constraints.  In  other  words,  all  the 
previous  presented  CD  macros,  including  M3.1,  M3.2,  and  M3.3,  are  simply  special  cases 
of  M3.4.  As  the  number  of  classes  in  M3.4  increases,  the  number  of  the  micro-rules  of 
M3.4  will  also  increase.  An  extension  of  the  micro-rules  is  straight-forward  using  the  rule 
specification  language.  Specifically,  several  additional  rules  are  needed  to  account  for  those 
ASSOCIATE  and  DISASSOCIATE  operations  on  objects  of  Xi  and  Xi+1,  i  =  l..k-l, 
since  their  executions  may  result  in  violations  on  the  two  lower  bounds  and  the  two  upper 
bounds  of  the  specified  cardinality  constraint.  (See  APPENDIX  A.3  for  detailed  micro-rule 
representation  of  M3.4,  where  the  rule-ids  are  re-arranged  and  are  different  from  those  we 
used  in  this  section.)  An  example  of  this  general  constraint  type  is  found  in  OSAM*  model. 
The  indirect  cardinality  constraint  in  the  OSAM*  schema  S4  of  Figure  5.2  can  be 
represented  in  M3.4  form  with  the  indices  m  =  k  =  n  =  1.  In  this  schema,  the  Employee 
and  Project  classes  are  indirectly  associated  through  the  Works_for  class  and  their  mapping 
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relationship  is  specified  asg  [3,  15]  :  [1,  2],  meaning  an  employee  can  work  for  at  most 
two  projects  and  a  project  can  have  at  least  three  and  at  most  fifteen  employees.  This 
constraint  can  be  translated,  using  M3.4,  into  its  macro  representation  "CD((-,  Employee, 
-),  (Works_for,  -),  (-,  Project,  -),  3,  15,  1,  2)"  in  which  no  attribute  names  and  no 
selection  conditions  are  specified. 

5.2.3  INHERITANCE  (IH) 

Inheritance  is  a  modeling  mechanism  which  allows  object  attributes,  operations, 
and  rules  of  a  superclass  to  be  inherited  by  objects  of  a  subclass.  It  is  a  very  useful  and 
commonly  supported  modeling  construct  available  in  most  new  generation  of  semantic  and 
object-oriented  data  models.  However,  in  more  traditional  data  models  such  as  the 
relational  model  and  the  E-R  model,  this  construct  is  not  supported.  To  accommodate  both 
types  of  data  models,  ORECOM  does  not  treat  the  inheritance  as  one  of  its  basic  structural 
constructs.  Instead,  it  is  treated  as  a  basic  constraint  type  whose  semantics  is  expressed  by 
rules.  The  following  IH  macro  and  its  micro-rule  illustrate  one  aspect  of  the  operational 
semantics  of  inheritance. 

Macro:  IH  (X,  Y)  (M4.1) 
Micro: 

rule  IH-01  is    /*  defined  in  class  Y  (the  subclass)  */ 

triggered  before  this.att,  this.DISASSOCIATE(att,  v),  this.ASSOCIATE(att,  v),  this.op 
condition  (not  In(att,  this.LocalAttribute))  v  (not  In(op,  this.LocalOperation))  I 

exist  x  in  ((this  *>  x:X)  where  OID(this)  =  OID(x)) 
action       x  $  this.thisOperation; 

The  IH  macro  has  two  parameters:  X  specifies  a  superclass,  and  Y  specifies  a 
subclass.  The  six  inheritance  constructs  of  EXPRESS,  IDEF-1X,  NIAM,  OSAM*,  SDM, 
and  OMT  shown  in  Figure  2  can  be  uniformly  represented  in  ORECOM  as  'TH(Employee, 
Secretary)".  The  IH  macro  is  an  inter-class  constraint  type.  If  a  superclass  has  more  than 
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one  subclass,  then  each  superclass-subclass  association  will  be  represented  by  an 
individual  IH  macro.  For  example,  in  the  NIAM  schema  S5  of  Figure  5.2  where  the 
Student  object  type  is  a  supertype  of  both  Full_Time_Student  and  Part_Time_Student 
object  types,  the  inheritance  of  these  two  associations  is  represented  by  "IH(Student, 
Full_Time_Student)"  and  "IH(Student,  Part_Time_Student)",  respectively.  Similarly,  in 
the  case  of  multiple  inheritance,  there  will  be  one  IH  macro  for  each  association  between 
the  subclass  and  one  of  its  superclasses.  Other  constraints  between  the  superclass  and  the 
subclass  (e.g.,  existence  dependency,  cardinality,  or  the  discriminator  specification  as 
required  by  the  IDEF-1X  model)  and  among  the  multiple  superclass-subclass  associations 
(e.g.,  total  specialization,  set  exclusion,  set  subset,  etc.)  are  represented  by  other  types  of 
macros. 

The  semantics  of  one  aspect  of  inheritance  is  described  by  micro-rule  IH-01,  which 
is  defined  in  the  subclass  of  the  association  identified  by  Y.  Generally  speaking,  this  rule 
allows  an  operation  defined  in  a  superclass  to  be  performed  on  objects  of  a  subclass.  The 
four  triggering  operations  of  the  rule  IH-01  are  attribute  retrieval,  attribute  association, 
attribute  disassociation,  and  activation  of  a  user-defined  operation.  In  these  triggering 
specifications,  'this'  represents  a  Y  object,  'att'  and  V  represent  an  attribute  and  its  value, 
and  'op'  represents  a  user-defined  operation.  A  prerequisite  condition  for  evaluating  the 
rule  body  is  that  an  attempt  is  made  to  access  or  manipulate  an  attribute  (att)  or  to  perform 
an  operation  (op).  The  condition-clause  of  IH-01  is  a  guarded  expression  which  states  that, 
if  the  attribute  being  retrieved  or  manipulated  or  the  operation  being  performed  is  not  a 
member  of  the  set  of  attributes  or  operations  defined  in  class  Y,  then  we  want  to  check  if 
there  exists  an  object  instance  in  class  X  that  corresponds  to  "this"  Y  instance  having  the 
same  OID.  If  both  conditions  verified  in  sequence  are  true,  then  the  triggering  operation  is 
aborted  to  be  performed  on  the  corresponding  X  object.  This  is  done  by  using  a  casting 
operator  "$"  which  replaces  the  original  operand,  a  Y  object  instance  (this),  with  its 
corresponding  superclass  object  instance  (x)  to  avoid  a  type  checking  error. 


49 


The  general  concept  of  inheritance  should  apply  to  not  only  the  inheritance  of 
attributes  (or  associations)  and  operations  but  also  the  inheritance  of  rules.  However,  it  is 
noted  that  the  definition  of  IH-01  dose  not  show  the  rule  inheritance.  This  is  because  that 
references  to  the  inherited  attributes  and  operations  in  a  subclass  are  replaced  by  references 
of  these  attributes  and  operations  defined  in  its  superclass.  Processing  of  these  inherited 
attributes  and  operations  are  thus  automatically  subject  to  the  semantic  rules  of  the 
superclass.  In  other  words,  the  function  of  rule  inheritance  is  achieved  by  the  object  casting 
mechanism. 

In  the  following,  a  more  general  IH  macro  is  given  to  allow  selection  conditions  to 
be  used  with  both  superclass  and  subclass.  The  micro-rule  representation  of  this 
generalized  IH  macro  is  slightly  modified  from  what  is  shown  as  IH-01  above  and  is 
defined  in  the  APPENDIX  A.4.  To  our  knowledge,  none  of  the  existing  models  provide  an 
explicit  way  to  model  the  inheritance  property  for  some  selected  objects.  However,  such 
restriction  could  have  been  introduced  in  a  model  or  defined  by  user-defined  rules. 

Macro:   IH  (X,  Px,  Y,  PY)  (M4.2) 

This  general  IH  macro  does  not  change  the  original  semantic  property  of  inheritance 
represented  by  M4.1  and  its  micro-rule.  It  only  restricts  the  inheritance  to  those  X  and  Y 
objects  which  satisfy  Px  and  Py,  respectively.  We  use  the  NIAM  schema  S5  of  Figure  5.2 
again  to  illustrate  this  "conditional  inheritance"  concept.  In  this  original  schema,  every 
Full_Time_Student  object  can  inherit  an  attribute,  say,  GPA,  and  an  operation,  say, 
DisplayTranscript(),  from  its  corresponding  Student  object.  Now,  it  is  assumed  that  a 
Full_Time_Student  object  can  inherit  GPA  or  Display Transcript()  if  and  only  if  the  local 
attribute  Status  of  the  Full_Time_Student  object  is  equal  to  "tuition-paid"  aji<i  the  local 
attribute  Major  of  the  Student  object  is  not  equal  to  "CIS".  This  conditional  inheritance  is 
made  possible  by  adding  the  two  selection  conditions,  (Student.Major  *  "CIS")  and 
(Full_Time_Student.Status    =    "tuition-paid"),    to    the    macro  IH(Student, 
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Full_Time_Student).  If  a  student  whose  major  is  CIS  or  a  full  time  student  who  has  not 
paid  his  or  her  tuition,  then  the  inheritance  property  will  not  be  applicable  to  this  student. 

5.2.4  PRIVACY  (PV) 

Constraints  of  this  category  provide  access  protections  to  the  structural  and 
behavioral  properties  of  objects.  An  association  between  two  classes  can  be  declared  to  be 
private,  protected,  or  public.  For  example,  suppose  a  is  an  attribute  defined  in  class  X, 

whose  domain  is  class  Y.  If  this  attribute  (or  association  between  X  and  Y)  is  private,  then 
only  objects  of  X  can  initiate  operations  to  access  the  Y  objects  that  are  associated  with  the 
X  objects  through  a  or  to  associate  or  disassociate  with  Y  objects.  This  type  of  privacy 
constraint  can  also  be  applied  to  a  superclass-subclass  construct.  For  example,  if  X  is  a 
subclass  of  Y,  only  X  objects  can  initiate  an  inherited  operation  or  access  an  inherited 
attribute  from  class  Y  and  Y's  superclasses.  In  both  modeling  constructs,  the  association  is 
private  or  "invisible"  to  all  other  objects  associated  with  class  X.  For  a  protected 
association,  on  the  other  hand,  the  privilege  of  traversing  the  association  to  access  Y 
objects  and  its  attributes  and  operations  is  also  granted  to  objects  of  the  subclasses  of  X.  In 
this  case,  if  class  Z  is  a  subclass  of  X  and  X  is  a  protected  subclass  of  Y,  then  objects  of  Y 
and  its  superclasses  and  their  operations  and  attributes  will  be  all  inheritable  to  both  X  and 
Z  objects.  Similarly,  if  Y  is  the  domain  of  the  protected  attribute  a  of  X,  and  z  represents  a 
subclass  object  of  Z,  then  the  retrieve  operation  "z.cc"  will  be  granted.  An  association 
which  is  neither  private  nor  protected  is  accessible  to  all  objects  and  is  called  a  public 
association. 

Privacy  constraints  are  not  commonly  supported  by  the  existing  data  models. 
However,  they  are  supported  by  some  object-oriented  programming  languages  such  as 
C++.  The  two  simple  C++  schemata  shown  in  Figure  5.4  give  some  examples  of  privacy 
constraints.  In  schema  S7,  the  Employee  class  has  a  public  attribute  Eid,  a  protected 
attribute  Address,  and  a  private  attribute  Salary.  The  Eid  can  be  accessed  by  objects  of  all 
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classes  since  it  is  public.  The  Salary  is  a  private  attribute  and  therefore  can  be  accessed  and 
updated  by  Employee  objects  only.  All  other  indirect  accesses  from  outside  the  Employee 
class  (e.g.,  a  subclass)  are  not  permitted.  The  last  attribute,  Address,  is  protected  but  not 
private.  In  addition  to  the  Employee  objects,  objects  of  Employee's  subclasses  are  also 
allowed  to  access  this  attribute.  In  schema  S8,  the  superclass-subclass  association  between 
the  Employee  and  Manager  classes  is  defined  to  be  a  private  association.  Because  of  this 
privacy  constraint,  the  inheritance  of  Employee's  instances,  attributes,  and  operations  is 
limited  to  objects  of  Manager  only.  They  can  neither  be  further  inherited  by  subclasses  of 
Manager  nor  be  accessible  to  Manager's  other  associated  classes.  The  C++  privacy 
constraints  have  been  adopted  in  the  underlying  data  model  of  our  implemented  knowledge 
base  programming  language  K.l  [ARR92]. 

S7  (C++)  S8  (C++)  

class  Employee  class  Manager:  private  Employee 

{  { 
public:  public: 

int  Eid;                          int  Office*; 
protected:   

char  *Address;  } ; 

private: 

float  Salary; 

}; 

Figure  5.4.  Examples  of  public,  protected,  and  private  associations  in  C++. 


Macro:  PV(  X,  a,  Y,  privacy_type  )  (M5.1) 
Micro: 

rulePV-01  is    /*  defined  in  class  X  */ 

triggered  before  this.a,  this. ASSOCIATED,  y),  this.DISASSOCIATE(a,  y), 

y  $  this.thisOperation 
condition  ((privacy_type  =  "private")  =>  (this.prior  =  this))  OR 
((privacy_type  =  "protected")  => 

((this.prior  =  this)  OR  ((this.prior  *>  this)  AND  (OID(this.prior)  =  OID(this))))) 
otherwise  REJECT; 
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The  PV  macro  shown  in  M5.1  is  a  general  form  to  represent  the  above  privacy 
constraints.  The  same  macro  can  represent  a  privacy  constraint  of  a  superclass-subclass 
association  or  a  simple  association  between  two  classes.  The  value  of  the  parameter 
'privacy_type'  can  be  specified  as  "private"  or  "protected".  Using  this  PV  macro,  the 
privacy  constraints  in  S7  and  S8  of  Figure  5.4  are  represented  as  follows: 

S7:  PV(Employee,  Salary,  float,  private) 
S7:  PV  (Employee,  Address,  char,  protected) 
S8:  PV(Manager,  -,  Employee,  private) 

The  PV  macro  is  enforced  by  the  micro-rule  PV-01.  This  rule  is  defined  in  class  X 
and  can  be  triggered  by  two  sets  of  operations,  depending  on  whether  there  is  inheritance 
on  the  association.  If  there  is  no  inheritance,  then  PV-01  can  be  triggered  by  one  of  the 
three  operations:  this.ct,  this.ASSOCIATE(oc,  y),  or  this.DISASSOCIATE(oc,  y).  If  Y  is  a 
superclass  of  X,  then  it  can  be  triggered  by  a  casting  operation  which  transfers  an  operation 
from  class  X  to  class  Y.  The  main  task  of  PV-01  is  to  find  out,  through  the  use  of  a 
system-defined  method  called  prior,  the  object  which  initiates  the  triggering  operation.  It 
can  be  the  current  operated  X  object  identified  by  'this',  or  objects  of  other  classes.  For  the 
former  case,  the  method  "this.prior"  will  return  a  value  which  is  the  instance  identifier  (IID) 
of  the  object  represented  by  'this'.  The  returned  value  must  equal  to  'this'  for  a  private 
association,  because  only  objects  of  X  can  initiate  the  triggering  operations.  However,  for  a 
protected  association,  the  value  of  "this.prior"  can  be  equal  to  'this'  or  the  IID  of  a  subclass 
instance  of  'this'.  In  our  last  example  shown  in  Figure  5.4,  we  can  assume  Secretary  is 
another  subclass  of  Employee  and  let  'sOOl'  and  'eOOl'  represent  the  IIDs  of  the  person  in 
the  Secretary  and  Employee  classes,  respectively.  Then,  the  operation  "sOOl. Salary"  will 
be  replaced  with  another  operation  "eOOl  $  sOOl. Salary"  and  before  it  is  executed,  the  rule 
PV-01  in  Employee  class  is  triggered.  In  evaluating  this  PV-01,  the  value  returned  by  the 
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method  "eOOl. prior"  is  sOOl,  not  eOOl.  According  to  the  private  constraint  which  requires 
"eOOl.prior"  to  be  equal  to  eOOl,  the  operation  "eOOl  $  sOOl. Salary"  and  hence  the  original 
"sOOl. Salary"  will  thus  be  rejected.  On  the  other  hand,  the  retrieve  operation 
"sOOl.  Address"  will  be  accepted  since  Address  is  a  protected  attribute  of  Employee  and  can 
be  accessed  by  the  subclass  objects  of  Employee  (e.g.,  sOOl). 

The  following  macro  is  a  generalized  PV  macro  of  M5. 1 ,  which  allows  selection 
conditions  to  be  specified  with  both  classes. 

Macro:  PV(  X,  Px,  a,  Y,  PY,  privacyjype  )  (M5.2) 

As  in  other  generalized  macros,  the  purpose  of  adding  the  selection  conditions  Px  and  Py  to 
this  macro  is  to  allow  the  specified  privacy  constraint  to  be  applied  on  selected  objects.  For 
example,  in  the  macro  "PV(Employee,  Employee.Position  >  5,  Salary,  Float,  Float  > 
100K,  private)",  the  Salary  is  specified  to  be  a  private  attribute  of  Employee,  but  the 
privacy  is  only  for  those  employees  whose  Position  value  is  greater  than  five  and  the  Salary 
value  is  higher  than  100K.  Micro-rule  representation  of  M5.2  would  be  similar  to  that  of 
M5.1  except  that  the  condition-clause  has  to  be  modified  to  include  the  verification  of  the 
two  selection  conditions  (see  APPENDIX  A.  5  for  detail). 

5.2.5  TRANSITION  CTS) 

This  type  of  constraints  deal  with  updating  an  association  or  the  transition  of  an 
association  from  one  state  to  another.  Upon  updating  an  association,  one  object  is 
disassociated  from  the  other,  and  it  may  or  may  not  be  associated  again  with  another  object 
in  the  same  class.  A  transition  constraint  can  be  defined  in  this  situation  to  regulate  how  an 
association  can  be  changed.  Though  most  existing  data  models  do  not  provide  explicit 
notations  or  facilities  for  specifying  a  transition  constraint,  it  is  an  important  constraint  type 
in  database  applications.  We  take  the  IDEF-1X  schema  SI  in  Figure  5.2  as  an  example. 
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The  SSN  in  this  schema  is  an  alternate  key  of  the  Employee  entity.  Since  a  key  is  normally 
not  updatable  once  its  value  has  been  given,  there  must  exist  a  "non-updatable"  constraint 
for  this  attribute.  This  non-updatable  constraint  is  one  example  of  transition  constraints.  A 
transition  constraint  can  also  be  used  to  specify  the  relationship  between  the  two  values  of 
an  attribute  before  and  after  its  update.  For  instance,  a  transition  constraint  can  be  added  to 
the  Salary  attribute  of  Engineer  in  the  SDM  schema  S3  in  Figure  5.2  so  that  an  engineer's 
salary  can  only  be  increased  and  the  increment  should  be  at  least  10%  of  its  current  value. 
A  rule  like  this  is  an  application  dependent  transition  constraint  and  has  to  be  defined  or 
implemented  in  an  application  program.  To  represent  and  enforce  a  transition  constraint  in  a 
general  manner,  no  matter  how  it  is  actually  defined  or  implemented  and  no  matter  what 
special  language  is  used,  we  define  the  following  TS  macro  and  micro-rules. 


Macro:  TS  (  X,  a,  Y,  texp(a,  a_old)  ) 

Micro: 

rule  TS-01  is    /*  defined  in  class  X  */ 
triggered  before  this.DISASSOCIATE(cc,  y) 
action       this.a_old  :=  y; 


(M6.1) 


rule  TS-02  is    I*  defined  in  class  X  */ 
triggered  before  this.ASSOCIATE(oc,  y) 
condition  this.a_old  *  nil  I  texp(y,  this.a_old) 
otherwise  REJECT; 

The  TS  macro  in  M6. 1  is  an  inter-class  constraint  type,  which  specifies  a  transition 
rule  in  the  parameter  'texp'  for  the  two  associated  classes,  X  and  Y.  These  two  classes  are 
associated  with  each  other  through  an  association  named  a,  and,  as  specified  in  the  order 
given  in  the  macro,  a  serves  as  an  attribute  of  X  with  its  domain  Y.  The  two  arguments  of 
the  parameter  texp  (i.e.,  a  and  ct_old)  hold  separately  the  current  value  of  the  attribute  and 
the  old  value  before  the  current  one  is  assigned.  These  two  values  should  satisfy  the 
transition  rule  specified  by  texp.  Otherwise,  the  last  update  of  this  attribute  that  changes  its 
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value  from  the  value  of  a_old  to  that  of  a  would  have  violated  the  constraint.  Here  we 
assume  that  the  a_old  is  a  system-generated  attribute  which  records  the  old  value  of 
attribute  a  during  an  update.  Using  M6.1,  the  above  example  of  non-updatable  SSN 
attribute  of  the  Employee  entity  can  be  represented  as  "TS(Employee,  SSN,  Integer, 
Employee.SSN  =  Employee. SSN_old)".  And,  the  example  of  the  increase-only  Salary 
attribute  of  the  Engineer  class  can  be  represented  by  the  macro  "TS (Engineer,  Salary,  Real, 
Engineer.Salary  >  1.1  *  Engineer.Salary_old)". 

An  attribute  update  is  carried  out  in  ORECOM  by  two  primitive  operations,  i.e.,  a 
DISASSOCIATE  operation  for  removing  the  old  value  and  an  optional  ASSOCIATE 
operation  for  assigning  a  new  value.  Therefore,  the  enforcement  of  a  transition  rule  can  be 
achieved  in  two  steps.  First,  the  current  attribute  value  has  to  be  recorded  before  it  is 
removed,  and  then,  the  rule  is  evaluated  using  the  recorded  value  and  the  new  value.  These 
two  steps  are  carried  out  by  the  micro-rules  TS-01  and  TS-02,  respectively.  Both  of  them 
are  defined  in  the  X  class,  i.e.,  the  owner  of  the  attribute  a.  The  rule  TS-01  simply  puts  the 
current  attribute  value  identified  by  'y'  into  a_old  before  the  DISASSOCIATE  operation 
removes  it  from  the  X  object  identified  by  'this'.  Then,  in  rule  TS-02,  before  an  X  object  is 
associated  with  another  Y  object  (identified  by  'y')  as  its  new  attribute  value,  the  Y  object 
and  the  one  recorded  in  a_old  are  evaluated  together  to  see  if  this  attribute  update  satisfies 
the  transition  rule  specified  in  texp.  If  the  evaluation  of  texp  failed,  the  ASSOCIATE 
operation  is  rejected. 

There  are  two  things  to  be  noted  about  the  TS  macro  and  its  micro-rules.  First,  in 
defining  the  TS  macro  and  its  micro-rules,  we  have  made  an  assumption  that  the 
represented  transition  rule  applies  to  only  those  X  objects  whose  a  values  have  been 
assigned.  For  examples,  the  constraint  of  non-updatable  SSN  would  not  be  applicable  to 
employees  whose  SSNs  have  never  been  filled,  and  similarly,  the  constraint  of  at  least  10% 
increase  on  Salary  would  not  be  applicable  to  engineers  whose  salaries  have  not  been 
decided.  In  general,  if  an  X  object  whose  a  attribute  has  never  been  assigned  a  value,  then 
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its  cc_old  value  is  kept  as  null  by  default.  Therefore,  according  to  this  assumption,  the 
evaluation  of  the  transition  rule  texp  would  not  be  executed  unless  "this.a_old  *  nil". 
Second,  although  a  TS  macro  contains  two  micro-rules,  it  is  not  necessary  that  both  are 
fired  for  a  same  update.  It  is  possible  that  only  TS-01  is  fired  if  an  update  removes  an 
attribute  value  without  assigning  a  new  value.  It  is  also  possible  that  only  TS-02  is  fired  if 
an  update  assigns  a  value  to  an  attribute  whose  current  value  is  null.  For  examples,  an 
employee's  SSN  can  be  removed  in  one  update  and  re-assigned  in  another  update.  The 
original  non-updatable  rule  still  holds  even  the  two  micro-rules,  TS-01  and  TS-02,  are 
triggered  by  two  separate  updates. 

The  TRANSITION  constraint  type  defined  in  M6.1  can  be  further  generalized,  just 
like  the  other  constraint  types  we  have  discussed,  so  that  it  can  be  applied  only  to  some 
selected  subsets  of  objects.  The  generalized  TS  macro  with  its  micro-rule  representation  is 
available  in  APPENDIX  A.6  of  this  dissertation. 

5.2.6  MATHEMATICAL-DEPENDENCE  (MP) 

This  macro  is  an  inter-association  constraint  type.  A  set  of  attributes  of  a  class  are 
mathematically  dependent  if  one  attribute  can  be  derived  from  the  others  by  using  a 
mathematic  formula.  A  mathematic  formula  can  be  specified  with  arithmetic  functions  and 
operators  such  as  'sin',  'log',  'sqr'  and  '+',  '-',  '*',  V,  '**',  etc.  It  is  possible  for  a 
mathematic  formula  to  be  specified  in  many  different  but  mathematically  equivalent  ways. 
For  example,  a  formula  for  the  attributes  a,  b,  c,  and  d  of  some  class  could  be  in  the  form 
of  "a  =  b  +  c  -  d",  or  "a  -  b  =  c  -  d",  or  "a  +  d  =  b  +  c",  and  so  on.  Such  a  formula 
specifies  a  "value  relationship"  constraint  for  the  related  associations  which  needs  to  be 
maintained  during  data  entry  and  update.  An  example  of  this  type  of  constraints  can  be 
found  in  the  SDM  schema  S3  shown  in  Figure  5.2.  In  this  schema,  the  formula  "Salary  = 
Position  *  325.3  +  20000"  derives  a  Salary  value  from  a  Position  value  and  it  also  imposes 
a  mathematical  dependence  constraint  upon  the  two  attributes  so  that  if  one  is  updated,  the 
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other  one  must  also  be  updated  accordingly.  Similar  formulas  can  also  be  defined  in  other 
models  such  as  EXPRESS,  OSAM*,  and  NIAM. 

The  following  MD  macro  and  the  micro-rule  MD-01  provide  a  general  form  to 
represent  and  enforce  a  mathematical  dependence  constraint  on  the  associations  or  attributes 
ccl,  ct2, an  of  the  class  X.  The  constraint  is  specified  as  a  function  mexp(ccl, an) 
which  returns  TRUE  or  FALSE.  The  classes  Yl,  Y2, and  Yn  are  domains  of  al,  a2, 
and  an,  respectively. 

Macro:  MD  (X,  ((al,  Yl)...(an,  Yn)),  mexp(al,  an))  (M7.1) 
Micro: 

rule  MD-01  is    /*  defined  in  class  X  */ 

triggered    immediate_after  this.ASSOCIATE(al,  yl),  , 

immediate_after  this.ASSOCIATE(an,  yn) 
condition  exist  this  in  (this  AND(*>al  yl:Yl, ..,  *>an  yn:Yn))  I  mexp(yl...yn) 
otherwise  REJECT; 

The  value  relationship  between  the  attributes  Salary  and  Position  has  the  MD  macro 
representation  "MD(Engineer,  ((Salary,  Real),  (Position,  Integer)),  Salary  =  Position  * 
325.3  +  20000)".  This  value  relationship  needs  to  be  maintained  whenever  an  engineer  has 
both  Salary  and  Position  values.  In  the  micro-rule  MD-01,  the  condition  clause  specifies  a 
guarded  expression  which  is  verified  after  an  X  object  (i.e.,  this)  is  associated  with  some  yi 
through  the  association  named  ai.  The  function  mexp  is  evaluated  if  the  X  object  is 
associated  with  objects  yl,  y2,  and  yn  through  the  associations  al,  a2, and  an, 
respectively.  In  the  evaluation,  the  function  mexp(al, an)  is  instantiated  to  mexp(yl, 
yn).  A  false  result  will  cause  the  triggering  ASSOCIATE  operation  to  be  rejected  and 
aborted.  We  note  that  the  trigger  of  the  rule  contains  associate  operations  only.  Disassociate 
and  retrieve  operations  are  not  included  because  their  execution  will  not  affect  the  value 
relationship  of  the  attributes. 


58 

The  next  representation  M7.2  is  a  generalized  MD  macro,  which  allows  a 
mathematical  dependence  constraint  to  be  applied  on  subsets  of  objects  selected  by  the 
expressions  PY1,  PY2,      and  PYn. 

Macro:  MD  (X,  Px,  ((ccl,  Yl,  PYi)...(ccn,  Yn,  PYn))>  mexp(ccl,  an)) 
(M7.2) 

An  example  of  this  generalized  MD  macro  is  "MD(Engineer,  Engineer.Degree  =  "ME", 
((Salary,  Real,  -),  (Position,  Integer,  Integer  <  25)),  Salary  =  Position  *  325.3  +  20000)". 
The  same  formula  now  is  not  applicable  to  all  engineers  due  to  the  added  selection 
conditions.  Only  those  engineers  whose  degree  is  "ME"  and  whose  positions  are  lower 
than  25  can  use  the  formula  to  decide  their  salaries.  In  addition,  every  engineer's  salary 
must  be  re-verified  whenever  his/her  degree  or  position  is  updated,  no  matter  he/she 
originally  satisfies  the  selection  conditions  or  not.  This  is  necessary  because,  after  an 
update  of  degree  or  position,  an  engineer  may  become  qualified  with  respect  to  the  two 
selection  conditions,  which  means  the  engineer's  salary  has  to  be  adjusted  to  satisfy  the 
formula.  In  terms  of  micro-rule  representation,  the  verification  of  the  selection  conditions 
has  to  be  incorporated  into  the  rule  MD-01,  and  more  micro-rules  are  needed  to  account  for 
those  operations  that  change  the  qualification  of  objects  with  respect  to  the  selection 
conditions.  (See  APPENDIX  A.7  for  detailed  definition.) 

5.2.7  LOGICAL-DEPENDENCE  (LP) 

This  type  of  constraints  specify  some  logical  relationships  among  a  set  of 
associations  of  a  class.  A  logical  relationship  can  be  specified  in  a  general  way  using  a 
quantified  association  pattern  such  as  "forall  x  in  x:X  suchthat  exist  yl,  y2  in  (x  OR(*>ocl 
yl:Yl,  *>a2  y2:Y2))",  which  means  every  X  object  must  have  at  least  one  of  the  two 
associations,  al  or  a2,  with  Yl  or  Y2  object.  An  example  of  a  logical  relationship  existing 
in  the  two  associations  between  the  Student  class  and  the  Full_Time_Student, 
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Part_Time_Student  classes  is  illustrated  in  the  NIAM  schema  (S5)  in  Figure  5.2.  These 
two  associations  are  logically  dependent  on  each  other  because  of  the  "EXCLUSION" 
constraint  denoted  by  the  symbol  "X".  Due  to  this  EXCLUSION  constraint,  the  two 
associations  can  not  co-existed.  That  is,  a  student  can  be  either  a  full  time  student  or  a  part 
time  student,  but  not  both.  In  OSAM*  model,  a  different  symbol  "SX"  meaning  "SET- 
EXCLUSION"  is  used,  and  in  EXPRESS,  it  is  represented  by  "ENTITY  Student 
SUPERTYPE  OF  (ONEOF  (Full_Time_Student,  Part_Time_Student));",  where  the  key 
word  "ONEOF"  means  that  a  student  can  only  be  in  one  of  the  subclasses.  This  constraint 
can  be  uniformly  specified  in  ORECOM  by  the  following  quantified  expression: 


AND 


forall  s  in  (s:Student  *>  Full_Time_Student) 
suchthat  NOT  exist  p  in  (s  *>  p:Part_Time_Student) 

forall  s  in  (s:Student  *>  Part_Time_Student) 
suchthat  NOT  exist  f  in  (s  *>  f:Full_Time_Student) 


(lexpl) 


The  NIAM  schema  shown  in  Figure  5.5  demonstrates  another  example  of 
LOGICAL-DEPENDENCE  constraints.  In  this  schema,  there  is  a  "SUBSET"  (S) 
constraint  between  the  two  associations  Pays  and  Enrolls  of  the  Student  class.  This 
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Figure  5.5.  A  NIAM  schema  with  a  "subset"  constraint. 


constraint  requires  that  the  set  of  students  who  have  paid  the  tuition  fee  must  be  a  subset  of 
those  who  have  enrolled  in  some  course(s).  The  subset  constraint  is  not  available  in 
EXPRESS  and  IDEF-1X  models,  but  it  is  equivalent  to  the  SET-SUBSET  (SS)  constraint 
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of  OSAM*  except  that  the  latter  is  defined  on  two  subclass  associations.  In  the  language  K, 
it  can  be  represented  more  generally  as  follows: 

forall  s  in  (s:Student  *>Pays  TuitionFee) 

suchthat  exist  c  in  (s  *>Enrolls  c:Course)  (lexp2) 

The  EXCLUSION  and  SUBSET  constraints  in  the  last  two  examples  are  both 
model-supported  constraints.  Many  user-defined  constraints  which  are  embedded  in 
application  programs  can  also  be  specified  by  logic  expressions.  For  example,  the 
following  conjunctive  expression  is  used  to  represent  a  special  constraint  for  the  two 
attributes  Position  and  Salary  of  the  SDM  schema  (S3)  in  Figure  5.2.  This  constraint  has  to 
be  implemented  in  a  program  to  meet  a  particular  application's  need  since  it  can  not  be 
captured  explicitly  in  the  referenced  SDM  schema. 

forall  e  in  (e:Engineer  *>Position  Integer) 
suchthat  exist  r  in  (e  *>Salary  r:Real) 

AND 

forall  e  in  (e:Engineer  *>Salary  Real) 

suchthat  exist  i  in  (e  *>Position  i:Integer)  (lexp3) 

According  to  the  original  schema,  both  Position  and  Salary  are  optional  attributes. 
However,  with  the  above  constraint,  if  an  engineer  has  one  of  these  two  attribute  values, 
the  other  attribute  must  also  be  assigned.  A  similar  kind  of  constraint,  called  SET- 
EQUALITY  (SE)  and  EQUALITY  (E),  is  supported  by  OSAM*  and  NIAM,  respectively. 

A  logical  dependence  constraint  can  be  used  to  specify  the  constraint  on  the  domain 
of  an  attribute.  An  example  of  this  is  the  first  local  rule  defined  in  the  WHERE  clause  of  the 
EXPRESS  schema  S2  in  Figure  5.2.  According  to  this  rule,  a  company's  Fax  number 
should  always  be  an  integer  less  than  9999999999.  In  the  form  of  a  logical  expression,  this 
can  be  specified  as  follows: 

forall  c  in  (c:Company  *>Fax  i:INTEGER) 

suchthat  (i  <  9999999999)  (lexp4) 
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In  the  following,  we  shall  introduce  a  more  general  form  in  terms  of  macro  and 
micro-rules  to  represent  the  various  logical  dependence  constraints  on  the  associations  ocl, 
a2,      and  an. 

Macro:  LD(X,((al,Yl),...,(ocn,Yn)),  Iexp(X,((al,Yl),...,(an,Yn))))  (M8.1) 
Micro: 

rule  LD-01  is    /*  defined  in  class  X  */ 

triggered    immediate_after  this.ASSOCIATE(al,  yl), 

immediate_after  this.ASSOCIATE(an,  yn), 

immediate_afterthis.DISASSOCIATE(al,  yl), 

immediate_after  this.DISASSOCIATE(ocn,  yn) 
condition    lexp(this,  ((al.Yl),      (an,  Yn))) 
otherwise  REJECT; 

The  function  lexp(X,  ((al,Yl), (an,  Yn)))  of  the  LD  macro  specifies  a  logical 
expression  in  the  language  K  for  associations  al,  a2,  an  of  the  class  X.  The  logic 
expression  can  be  a  simple  quantified  association  pattern  such  as  "forall  x  in  (x:X 
OR(*>al  Yl,  *>a2  Y2))  suchthat  exist  y3,  yn  in  (x  OR(*>a3  y3:Y3,  *>an 
yn:Yn))",  or  a  compound  quantified  association  pattern  with  Boolean  operators  NOT,  AND 
(A),  OR  (v),  and  logic  implication  (=>).  Using  M8.1,  the  above  examples  of  logical 
dependence  constraints  can  be  represented  as  follows: 

LD(Student,  ((-,  Full_Time_Student),  (-,  Part_Time_Student)),  lexpl) 
LD(Student,  ((Pays,  TuitionFee),  (Enrolls,  Course)),  lexp2) 
LD(Engineer,  ((Position,  Integer),  (Salary,  Real)),  lexp3) 
LD(Company,  (Fax,  INTEGER),  lexp4) 

The  micro-rule  LD-01  defined  in  the  class  X  is  the  only  rule  for  the  LD  macro.  Its 
main  task  is  to  evaluate  the  logic  expression  specified  in  a  LD  macro.  Since  the  logical 
relationship  among  the  associations  can  be  affected  by  any  update  of  the  associations,  the 
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micro-rule  can  be  triggered  by  an  ASSOCIATE  or  a  DISASSOCIATE  operation  on  any  of 
the  associations  al,  a2,  and  an.  When  LD-01  is  triggered,  the  argument  'X'  in  the 
specified  function  lexp(X,  ((al.Yl),  (an,  Yn)))  is  instantiated  to  the  X  object  of  the 
triggering  operation,  i.e.,  lexp(this,  ((al,Yl),  (an,  Yn))).  The  binding  of  other 
variables  for  Classes  Yl,  Y2, and  Yn  still  depends  on  their  original  quantifiers  in  the 
expression.  The  evaluation  of  lexp(this,  ((al,Yl), (an,  Yn)))  decides  if  the  triggering 
operation  has  to  be  rejected.  For  example,  in  the  second  LD  macro  shown  above,  if  a 
student  has  enrolled  in  only  one  course  and  he/she  has  paid  the  tuition  fee,  then  a 
disassociation  of  the  student  from  his/her  associated  course  will  be  rejected  because  it 
violates  the  "SUBSET"  relationship  described  in  the  logical  expression. 

The  macro  defined  in  M8.1  can  be  extended  to  include  some  selection  conditions 
for  the  involved  classes  as  below: 

Macro:  LD  (X,  Px,  ((al,Yl,PYi),  (an,Yn,PY„)), 

Iexp(X,  (al,Yl),       (an,  Yn)))  (M8.2) 

This  generalized  LD  macro  can  be  used  to  represent  logical  dependence  constraints  in  a 
more  general  way.  For  example,  there  can  be  a  number  of  different  logical  relationships 
exist  in  different  subsets  of  objects  on  the  same  set  of  associations.  This  can  be  illustrated 
by  a  modified  constraint  of  the  NIAM  schema  in  Figure  6.  The  original  SUBSET  (S) 
constraint  applies  to  every  student  in  the  schema.  By  modifying  it  as  shown  below,  only 
non-graduating  students  have  to  obey  the  same  subset  constraint. 

LD(Student,  Student.Status*'graduating',  ((Pays,  TuitionFee),  (Enrolls,  Course)),  lexp2) 

The  micro-rules  corresponding  to  the  generalized  LD  macro  need  to  be  modified  to 
include  the  selection  conditions.  Additional  micro-rules  are  also  needed  so  that  operations 
that  change  the  qualification  of  objects  of  X,  Yl,      or  Yn  with  respect  to  the  selection 
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conditions  Px,  Pyi>  Pyn  will  trigger  rules  to  verify  the  specified  logical  expressions, 
complete  micro-rule  representation  of  M8.2  can  be  found  in  APPENDIX  A.8. 


CHAPTER  6 
DATA  MODEL  ANALYSIS 


In  our  study,  we  have  examined  a  number  of  data  models  with  a  special  emphasis 
on  the  semantics-rich  models  such  as  IDEF-1X,  NIAM,  EXPRESS  and  OSAM*.  Our 
objective  is  to  use  the  ORECOM's  macro  representation  as  a  neutral  representation  to 
capture  the  underlying  semantic  properties  of  their  modeling  constructs  and  constraints.  We 
have  manually  translated  all  the  constructs  and  constraints  of  these  models  into 
parameterized  macros  each  of  which  can  be  further  expressed  by  a  set  of  micro-rules 
representing  the  operational  semantics  of  a  DBMS.  Additionally,  we  have  implemented  a 
schema  translation  system  to  demonstrate  the  workability  of  schema  translation  through  this 
neutral  representation.  In  the  following  sections,  we  shall  use  some  selected  constructs  and 
constraints  of  the  above  mentioned  four  data  models  as  examples  to  illustrate  the  concept  of 
semantic  decomposition.  (A  complete  analysis  of  these  four  models  is  given  in  APPENDIX 
B  of  this  dissertation.) 

6.1  IDEF-1X 

IDEF-1X  [L0086,  87]  is  an  extension  of  the  data  model  IDEF-1  (or  Integrated 
Computer-Aided  Manufacturing  Definition  Method  1).  IDEF-1  was  developed  in  the  late 
1970's  under  the  auspices  of  the  U.S.  Air  Force,  and  later  became  one  of  the  best  known 
data  modeling  techniques  in  the  industry.  This  model  is  a  hybrid  of  the  ER  model  and  the 
relational  model.  It  uses  the  concepts  of  entities,  attributes,  entity  relationships  to  express 
data  semantics  and  provides  a  nice  graphical  notation  for  representing  some  structural 
properties  and  constraints.  Table  6.1  shows  some  examples  of  IDEF-1X  construct  and 
constraint  patterns  and  their  corresponding  macro  representations.  Construct  patterns  I-C- 
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01  to  I-T-04-2  describe  an  entity,  an  attribute,  and  an  alternate-key  attribute,  respectively. 
These  concepts  are  commonly  supported  in  other  data  models  even  though  different 
terminologies  and  notations  have  been  used.  For  example,  corresponding  to  an  IDEF-1X 
entity,  NIAM  uses  non-lexical  object  type  (NOLOT)  and  OSAM*  uses  entity  class  (E- 
class).  An  IDEF-1X  alternate-key  is  captured  in  EXPRESS  and  NIAM  by  a  uniqueness 
constraint. 

The  construct  I-C-01  of  Table  6.1  is  an  IDEF-1X  entity  whose  semantic  properties 
can  be  represented  in  ORECOM  by  a  Membership  (MB)  macro.  This  macro  states  that  the 
IDEF-1X  entity,  X,  can  be  mapped  to  an  entity  class  of  ORECOM,  whose  members  are 
system-named  objects  and  has  an  external  identifier  (Yl,  Yn),  i.e.,  the  composite 
primary  key  of  X.  The  default  object  structure  of  X  is  'simple'  (denoted  by  the  first '-'  in 
the  macro),  and  the  class  type  is  'E-CLASS'  because  it  defines  a  set  of  system-named 
objects.  It  does  not  have  a  membership  constraint  nor  method  specifications  (denoted  by 
the  last  two  '-'s  in  the  macro).  The  pattern  I-C-05  captures  the  constraints  of  an  attribute 
(Y),  which  relates  instances  of  an  entity  class  (X)  to  instances  of  the  underlying  domain  Y 
(i.e.,  dom(Y)).  The  symbol  "(O)"  after  Y  means  that  it  is  an  optional  attribute  which  is 
represented  in  ORECOM  by  a  partial  participation  constraint:  the  first  Participation  (PT) 
macro  of  I-C-05.  On  the  other  hand,  not  all  instances  of  the  domain  of  Y  are  associated 
with  X  instances,  which  is  also  a  partial  participation  constraint  represented  by  the  second 
Participation  (PT)  macro.  The  mapping  between  entity  class  X  and  the  domain  class  of  Y  is 
many-to-one  which  is  captured  by  the  Cardinality  (CD)  macro  of  I-C-05.  If  Y  is  an 
alternate  key  (AK)  of  X  as  shown  in  I-T-04-2,  then  the  macros  in  I-C-05  need  to  be 
modified  to  capture  the  "non-null"  (or  total  participation)  constraint  and  the  "uniqueness" 
(or  one-to-one  cardinality  mapping)  constraint  associated  with  an  alternate-key  attribute. 
We  note  here  that  the  concepts  of  a  primary  key  and  an  alternate  key  can  be  similarly 
decomposed  into  participation  and  cardinality  constraints. 
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Table  6. 1.  Examples  of  IDEF-1X  construct  and  constraint  patterns. 


No. 


Pattern 


Macro  Representation 


l-C-01 


an 

entity 


Y1  ...  Yn 


MB(  X,  system-named,  (Y1...Yn),  -,  E-CLASS,  -,  - ) 


l-C-04 


an 

optional 
attribute 


Y(o) 


PT(  X,  -,  0,  count(X),  (Y,  dom(Y),  -) ) 

PT(  dom(Y),  -,  0,  count(dom(Y)),  (Y  •)  X,  -) ) 

CD((-),  (X,  -),  (Y,  dom(Y),  -),  1,M,  1,1) 


l-T-04-2 


an 

alternate- 
key 


Y(AK) 


PT(  X,  -,  count(X),  count(X),  (Y,  dom(Y),  - ) ) 
PT(  dom(Y),  -,  0,  count(dom(Y)),  (Y  \  X,  - ) ) 
CD((-),  (X,  -),(Y,  dom(Y),  -),1,1,1,1  ) 


l-C-05 


Y 


Q 

Z 

Z(FK)(0) 

PT(X, -,  0,  count(X),  (R  ",1Y,  -)) 
PT(  Y,  -,  0,  count(Y),  (R,  X,  - ) ) 
CD((-),  (X,  -),  (R-IY,  -),  1,M,  1,1  ) 


l-T-06-1 


Y 


fa  ^ 

z 

PT(X, -,  0,  count(X),  (R  ",1Y,  -)) 
PT(  Y,  -,  count(Y),  count(Y),  (R,  X,  - ) ) 
CD((-),  (X,  -),  (R  i  Y,  -),  1,  M,  1,  1  ) 


The  last  two  constructs  of  Table  6.1,  I-C-05  and  I-T-06-1,  are  two  examples  of 
entity  relationship  between  entities  X  and  Y  which  is  called  in  IDEF-1X  the  connection 
relationship.  The  former  (see  I-C-05)  is  graphically  represented  in  IDEF-1X  by  a  dashed 
line  labelled  with  a  verb  'R',  and  the  primary  key  of  entity  Y  is  a  foreign  key  (FK)  of  X.  In 
ORECOM,  we  treat  the  inverse  of  R  (i.e.,  R'1)  as  an  attribute  of  X  and  the  domain  of  R"1 
is  Y.  In  I-C-05,  the  foreign  key  Z  is  located  below  the  line  of  entity  X  and  is  an  optional 
attribute,  which  means  that  instances  of  X  do  not  have  to  be  associated  with  any  Y  instance 
(i.e.,  no  existence  dependency).  This  semantic  property  is  captured  in  ORECOM  by 
the  first  Participation  (PT)  macro.  The  black  dot  on  the  X  side  of  the  link  indicates  that  a  Y 
instance  can  be  connected  to  zero,  one,  or  many  instances  of  X,  which  implies  that  Y  is 
partially  participated  in  the  association  R  with  X.  This  property  is  captured  by  the  second 
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Participation  (PT)  macro.  The  cardinality  mapping  from  X  to  Y  in  I-C-05  is  many-to-one  as 
captured  by  the  Cardinality  (CD)  macro. 

Compared  with  I-C-05,  the  construct  I-T-06-1  is  more  constrained  in  two  ways. 
First,  the  foreign  key  becomes  a  part  of  the  primary  key  of  X,  which  enforces  an 
identifier  dependency  constraint  and  hence,  an  existence  dependency  constraint. 
Second,  every  Y  instance  must  be  associated  with  at  least  one  X  instance  (indicated  by  the 
symbol  "P").  The  identifier  dependency  is  depicted  in  IDEF-1X  by  a  solid  line  instead  of 
the  dashed  line  in  I-C-05,  and  the  entity  box  of  X  is  also  changed  to  a  round-cornered  box 
which  indicates  that  the  entity  X  is  identifier-dependent  on  at  least  one  other  entity  (e.g., 
entity  Y,  in  I-T-06-1).  This  constraint  is  represented  by  changing  the  first  Participation 
(PT)  macro  of  I-C-05  to  a  total  participation  constraint.  The  constraint  imposed  by  the 
symbol  "P"  is  represented  by  changing  the  second  Participation  (PT)  macro  of  I-C-05  to  a 
total  participation.  The  cardinality  is  not  changed,  i.e.,  it  is  still  many-to-one.  In  a 
connection  relationship  in  IDEF-1X,  a  label  "Z"  can  be  used  in  the  place  of  "P"  to  mean 
zero  or  one  Y  instance's  connection  to  X  instance.  This  constraint  can  be  similarly 
expressed  in  a  cardinality  macro  with  different  parameter  values. 

6.2  EXPRESS 

EXPRESS  [SCH89,  IS092]  is  an  information  modeling  language  which  is  a  strong 
candidate  for  an  international  standard  for  product  specification.  An  EXPRESS  schema 
defines  data  types  and  their  constraints.  The  definition  of  a  data  type  'positive'  is  shown 
below: 

TYPE  positive  =  INTEGER; 

WHERE  self>0; 
END_TYPE; 

The  above  is  called  a  defined  data  type  which  is  similar  to  the  domain  class  (D-class)  of 
OSAM*  and  the  lexical  object  type  (LOT)  of  NIAM.  However,  it  is  not  explicitly  supported 
by  IDEF-1X  since  all  domains  of  attributes  are  hidden  from  an  IDEF-1X  schema.  Table 
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6.2  shows  some  general  constructs  of  EXPRESS.  The  X  in  the  construct  E-C-08  is  a 
defined  data  type  whose  domain  is  Y  (which  is  implicitly  a  simple  data  type  in  EXPRESS). 
A  defined  data  type  can  have  a  domain  rule  specified  by  an  expression  'exp'  in  the  WHERE 
clause.  In  ORECOM,  this  construct  can  be  represented  by  a  Membership  (MB)  macro 
having  X  as  a  domain  class  (i.e.,  containing  self-naming  objects  because  the  domain  Y  is  a 
simple  type  containing  self-naming  objects)  and  the  expression  exp  as  its  membership 
constraint.  Since  every  member  of  the  defined  type  X  must  be  an  instance  of  Y  that  satisfies 
exp,  and  every  such  qualified  Y  instance  becomes  automatically  a  member  of  X,  two 
Participation  (PT)  macros  are  used  to  describe  these  two  total  participation  constraints.  In 
addition,  a  Cardinality  (CD)  macro  is  used  to  capture  the  one-to-one  mapping  relationship 
between  X  and  Y. 


Table  6.2.  Examples  of  EXPRESS  construct  and  constraint  patterns. 


No. 

Pattern 

Macro  Representation 

E-C-08 

TYPE  X  =  Y; 

WHERE  exp; 
ENDTYPE; 

MB(  X,  self-naming,  -,  -,  Y,  exp,  - ) 
PT(  X,  -,  count(X),  count(X),  (-,  Y,  exp  ) ) 
PT(  Y,  exp,  count(Y),  count(Y),  (-,  X,  -) ) 
CD((-),  (X,  -),  (-,  Y,  exp),  1,1,1,1  ) 

E-C-01 

SET  [k1,k2]  OFX 

MB(  Y,  self-naming,  -,  SET,  X,  -,  - ) 
PT(  Y,  -,  counl(Y),  count(Y),  (-,  X,  -) ) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),  (Y,  -),  (-,  X,  -),  1,M,k1,k2) 

E-T-1516-3 

ENTITY  X; 

DERIVE 

Y:[agg]W:=  exp(Z1...Zn); 
END_ENTITY; 

MD(  X,  -,  ((Y,  dom(Y),  -),  (Z1 ,  dom(Z1 ),  -)  

(Zn,  dom(Zn), -)),  Y  =  exp(Z1...Zn) ) 

E-T-1516-5 

ENTITY  X; 

WHERE  exp(Z1...Zn); 
END_ENTITY; 

LD(  X,  -,  ((Z1 ,  dom(Z1 ),  -)  (Zn,  dom(Zn),  -)), 

exp(Z1...Zn)) 
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For  defining  complex  data  types,  EXPRESS  provides  four  "aggregations"  (i.e., 
SET,  LIST,  BAG,  and  ARRAY),  which  can  be  used  in  any  combination  and  in  any  length 
(e.g.,  LIST  of  ARRAY  of  ARRAY  of  SET  of  INTEGER).  An  equivalent  feature  of  this  is 
supported  in  OSAM*  but  it  is  not  generally  available  in  other  existing  models.  In 
EXPRESS,  aggregations  can  be  used  in  the  TYPE  declaration  for  defined  data  types  or  in 
the  entity  declaration  for  defining  complex  domains  of  attributes.  In  either  case,  each 
aggregation  of  a  complex  data  type  is  viewed  in  ORECOM  as  defining  a  new  class  from  the 
base  (or  domain)  of  that  aggregation,  whose  members  are  complex  objects  having  the 
structure  specified  by  the  aggregation.  For  example,  the  "SET  of  INTEGER"  in  the  above 
example  will  be  treated  as  defining  a  new  class  from  INTEGER,  say,  SETJNTEGER,  and 
each  object  of  this  new  class  represents  a  set  of  INTEGER  objects.  Based  on  this 
SETJNTEGER,  a  higher  level  aggregation  such  as  "ARRAY  OF  SET  OF  INTEGER" 
would  define  another  new  class,  ARRAY_SET_INTEGER,  whose  members  represents 
arrays  of  objects  of  the  class  SETJNTEGER.  The  general  construct  shown  in  E-C-01  of 
Table  6.2  is  EXPRESS'S  way  of  specifying  an  aggregation  of  X  with  a  minimum  of  zero 
and  a  maximum  of  u  number  of  X.  It  can  be  translated  to  a  number  of  macros.  The 
Membership  macro  specifies  that  a  new  created  class  named  Y  is  defined  as  an  aggregation 
of  X  and  is  a  domain  class.  (Here  the  X  is  assumed  to  be  a  simple  data  type  or  an 
aggregation  of  simple  data  type  in  EXPRESS.)  The  'agg'  in  E-C-01  can  be  SET,  LIST,  or 
BAG  only,  because  the  lower  and  upper  bounds  of  the  other  aggregation  ARRAY  mean 
differently  and  need  to  be  represented  by  a  separate  construct.  The  lower  bound  of  the 
'agg'  in  E-C-01  is  zero,  which  means  that  an  instance  of  X  may  not  contain  any  Y  instance, 
and  also,  as  a  default  condition,  not  every  Y  instance  has  to  become  an  element  of  some 
aggregated  object  of  X.  Both  of  these  two  conditions  are  partial  participation  constraints 
and  therefore  can  be  represented  by  the  two  Participation  macros  in  E-C-01.  The  upper 
bound  (u)  of  the  'agg'  determines  the  cardinality  mapping  between  X  and  Y  as  many-to-u 
(or  M-to-u)  as  shown  in  E-C-01.  By  changing  the  parameters  of  the  macros  associated  with 
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this  construct,  a  number  of  other  similar  EXPRESS  constructs  such  as  an  aggregation  with 
a  non-zero  lower  bound  and  a  LIST  of  unique  elements,  can  be  represented. 

Besides  TYPE  declarations,  entity  declarations  are  the  major  part  of  an  EXPRESS 
schema.  The  definition  of  an  EXPRESS  entity  type  is  in  terms  of  its  properties  (or 
attributes),  each  of  which  has  an  associated  domain  and  an  optional  constraint  of  the 
domain.  An  attribute  can  be  further  constrained  to  be  a  non-optional  attribute,  a  unique 
attribute,  or  a  derived  attribute.  The  first  two  types  of  constraints  are  similar  to  the  non-null 
attribute  and  alternate-key  attribute  of  IDEF-1X  which  have  been  discussed  previously.  A 
derived  attribute  is  shown  in  E-T-1516-3  of  Table  6.2,  in  which  the  value  of  attribute  Y  is 
derived  by  the  expression  'exp(Zl...Zn)'.  Since  the  domain  of  Y  (i.e.,  [agg]  W)  can  be  a 
simple  data  type,  a  defined  data  type  (specified  in  the  TYPE  section),  an  entity  type,  or  a 
complex  data  type  specified  by  an  aggregation  of  W,  we  simply  use  'dom(Y)'  as  the 
general  representation  of  the  domain  of  Y.  To  capture  the  value  relationship  between  the 
values  of  Y  ( i.e.,  members  of  [agg]W)  and  the  domains  of  attributes  Zs  which  derive  Y 
values,  a  Mathematical-Dependence  (MD)  macro  is  used  to  specify  "Y  =  exp(Zl...Zn)". 

Another  way  to  specify  a  constraint  on  an  attribute  in  EXPRESS  is  to  define  a 
"local  rule"  in  a  WHERE  clause  as  illustrated  in  E-T-1516-5  of  Table  6.2.  It  specifies  that 
the  values  of  attributes  Zl,  Z2, and  Zn  of  each  entity  of  X  have  to  satisfy  a  local  rule 
expressed  by  an  expression  exp(Zl...Zn).  Two  examples  of  local  rules  are:  "Zl  -  10  >  Z2 
+  Z3"  and  "Zl  :=:  Z2".  The  symbol  ":=:"  in  the  second  expression  represents  an  instance 
equality  operator  for  two  entity  typed  attributes.  This  expression  returns  TRUE  if  both  Zl 
and  Z2  refer  to  the  same  entity  instance.  Similar  rule  specification  facility  is  also  available  in 
OSAM*,  but  each  has  its  own  rule  language  syntax.  In  E-T-1516-5,  the  local  rule  is 
represented  in  ORECOM  as  an  inter-association  constraint  using  a  Logical-Dependence 
(LD)  macro  as  shown  in  Table  6.2. 
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6.3  NIAM 

NIAM  is  an  information  modeling  methodology  pioneered  by  G.  M.  Nijssen 
[VER82].  This  model  is  sometimes  referred  to  as  a  "binary  semantic  model"  because  it 
provides  a  binary  representation  of  data,  semantics,  and  constraint.  The  building  blocks  of 
NIAM  are  lexical  objects  (LOTs),  non-lexical  objects  (NOLOTs),  associations  between 
LOTs  and  NOLOTs  (called  BRIDGEs),  and  associations  between  different  NOLOTs 
(called  IDEAs).  Furthermore,  both  BRIDGEs  and  IDEAs  are  composed  of  a  pair  of  ROLEs 
which  are  usually  verbs  that  describe  the  semantics  of  the  associations.  The  most 
interesting  feature  of  NIAM  is  that  it  supports  many  kinds  of  constraints  on  multiple 
associations.  Besides  the  UNIQUENESS  (U)  constraint,  which  is  similar  to  the  alternate- 
key  (AK)  of  IDEF-1X  or  the  UNIQUE  constraint  of  EXPRESS,  there  are  three  association 
constraints:  EQUALITY  (E),  EXCLUSION  (X),  and  SUBSET  (S).  These  constraints  are 
described  separately  in  the  patterns  of  N-C-08,  N-C-10,  and  N-C-15  in  Table  6.3.  In  these 
patterns,  the  NOLOTs  Yl  and  Y2  are  assumed  to  be  the  domains  of  attributes  al  and  a2  of 
X,  respectively.  We  show  these  constraints  in  a  pair  of  IDEAs  even  though  they  can  also 
exist  in  a  pair  of  BRIDGEs  or  between  an  IDEA  and  a  BRIDGE.  For  each  construct,  a 
Logical-Dependence  (LD)  macro  is  used  to  capture  the  constraint  in  ORECOM's 
representation.  Since  the  constraints  are  different,  the  logic  expressions  of  their 
corresponding  macros  are  different.  For  the  constraint  of  EQUALITY  (E)  in  N-C-08, 
objects  of  X  must  either  have  both  values  of  al  and  a2  or  none  of  them.  Therefore,  the 
logical  expression  for  N-C-08  would  be  as  follows: 

(forall  x  in  (x:X  *>al  Yl)  suchthat  exist  y2  in  (x  *>a2  y2:Y2)) 
AND  (forall  x  in  (x:X  *>a2  Y2)  suchthat  exist  yl  in  (x  *>al  yl:Yl)) 

This  conjunctive  association  pattern  expression  ensures  that  there  does  not  exist  any  X 
object  which  associates  with  only  one  of  the  two  classes,  Yl  or  Y2.  As  we  discussed  in  the 
section  on  the  LD  macro,  the  'X's  in  the  above  expression  will  be  bound  to  the  X  object 
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instance  of  a  triggering  operation  which  triggers  the  micro-rule  LD-01  to  evaluate  the 
expression. 


Table  6.3.  Examples  of  NIAM  construct  and  constraint  patterns. 


NO. 

Pattern 

Macro  Representation 

N-C-08 

a2  -{Y2) 

LD(  X,  -,  ((-,  Y1 ,  -),  (-,  Y2,  -)),  expl )  where 

expl  =  (forall  x  in  (x:X  *>a1  Y1)  suchthat  exist  y2  in 

(x  *>a2  y2:Y2))  AND 
(forall  x  in  (x:X  *>a2  Y2)  suchthat  exist  y1  in 

(x  *>a1  y1:Y1)) 

N-C-10 

[XJ  x 

LD(  X,  -,  ((-,  Y1 ,  -),  (-,  Y2,  -)),  exp2)  where 

exp2  =  (forall  x  in  (x:X  *>a1  Y1)  suchthat  NOT  exist 
y2  in  (x  *>a2  y2:Y2))  AND 
(forall  x  in  (x:X  *>a2  Y2)  suchthat  NOT  exist 
y1  in  (X*>a1  y1:Y1)) 

N-C-12 

> —  a1  — fYli 

lu(  a,  -,  ((-,  ii,        id,  -)),  expo)  wnere 

exp3  =  (forall  x  in  (x:X  *>a1  Y1)  suchthat 
exist  y2  in  (x  *>a2  y2:Y2)) 

N-C-15 

®-  O 

IH(  X,  -,  Y,  - ) 

PT(  X,  -,  0,  count(X),  (-,  Y,  - ) ) 

PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  - ) ) 

CD((-),  (X,  -),  (-,  Y,-),  1,  1,  1,  1  ) 

N-T-16-1 

PT(  X,  -,  count(X),  count(X),  ((-,  Y1,  -)  (-,  Yn,  -)) ) 

N-T-16-2 

LD(  X,  -,  ((-,  Y1,  - )  (-.  Yn,  -)),  exp4  )  where 

exp4  = 

(forall  x  in  (x:X  *>a1  Y1 )  suchthat  NOT  exist  y2  

yn  in  (x  AND(*>a2  y2:Y2  San  yn:Yn))) 

AND ....  AND 

(forall  x  in  (x:X  San  Yn)  suchthat  NOT  exist  y1  

yn-1  in  (x  AND(*>a1  y1:Y1  *>an-1  yn-1:Yn-1))) 
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The  constraint  of  EXCLUSION  (X)  shown  in  N-C-10  requires  that  no  object  of  X 
can  have  both  values  of  al  and  a2  at  the  same  time.  The  logical  expression  for  this 
constraint  in  the  Macro  representation  is: 

(forall  x  in  (x:X  *>al  Yl)  suchthat  NOT  exist  y2  in  (x  *>a2  y2:Y2)) 
AND  (forall  x  in  (x:X  *>a2  Y2)  suchthat  NOT  exist  yl  in  (x  *>al  yl:Yl)) 

The  semantics  of  the  SUBSET  (S)  constraint  of  N-C-15  is  that  the  set  of  X  objects  which 
have  an  al  value  is  a  subset  of  those  X  object  which  have  an  a2  value,  or  equivalently,  the 
association  al  between  an  X  object  and  a  Yl  object  implies  the  association  a2  between  that 
X  object  and  a  Y2  object .  The  logical  expression  for  this  constraint  is  shown  below. 

(forall  x  in  (x:X  *>al  Yl)  suchthat  exist  y2  in  (x  *>a2  y2:Y2)) 

In  addition  to  the  above  inter-association  constraints,  NIAM  allows  object  types  to 
form  a  supertype-subtype  hierarchy.  This  important  concept  is  supported  in  almost  every 
new  semantic  or  object-oriented  data  model,  e.g.,  the  generalization  (G)  of  OSAM*,  the 
supertype-subtype  of  EXPRESS  and  IDEF-1X.  What  is  shown  in  the  pattern  of  N-C-15  is 
a  supertype-subtype  constraint  of  NIAM  between  the  NOLOTs  X  and  Y.  Since  X  is  the 
supertype  of  Y,  Y  inherits  all  properties  of  X.  The  inheritance  semantics  of  this  construct  is 
represented  by  the  Inheritance  (IH)  macro  of  N-C-15.  The  two  Participation  (PT)  macros 
capture  the  partial  participation  of  X  with  Y  and  the  total  participation  of  Y  with  X,  and  the 
Cardinality  (CD)  macro  captures  the  one-to-one  mapping  between  X  and  Y. 

In  NIAM,  a  set  of  subtype  associations  may  have  two  kinds  of  constraints: 
TOTALITY  (T)  and  DISJOINT  (*).  The  construct  N-T-16-1  shows  a  TOTALITY  (T) 
constraint  on  the  subtypes  (Yl,  Y2, Yn).  This  constraint  states  that  the  union  of  all  the 
subtype  objects  should  be  equal  to  the  set  of  objects  of  X.  In  other  words,  X  is  totally 
participated  in  the  set  of  subtypes  (Yl,  Y2,  Yn).  This  TOTALITY  (T)  constraint  is 
called  a  "total  specialization"  in  OSAM*  and  IDEF-1X.  In  ORECOM,  it  is  neutrally 
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represented  by  an  inter-association  Participation  (PT)  macro  as  shown  in  N-T-16-1.  The 
second  type  of  constraint  among  subtypes  is  DISJOINT  (*)  as  shown  in  N-T-16-2.  It 
specifies  that  the  objects  of  each  subtype  of  X  can  not  overlap.  This  constraint  is  similar  to 
the  EXCLUSION  (X)  of  N-C-10  except  it  is  applicable  to  subtype  classes  only.  The 
DISJOINT  constraint  is  also  available  in  OSAM*  (i.e.,  the  set-exclusion  or  SX  constraint) 
and  EXPRESS  (i.e.,  the  ONEOF  constraint).  In  IDEF-1X,  however,  it  is  defined  as  a 
default  constraint  among  subtype  entities.  In  ORECOM,  the  DISJOINT  (*)  constraint 
specifies  a  logical  relationship  among  subtypes  and  therefore  is  captured  by  a  Logical- 
Dependence  (LD)  macro  containing  a  logic  expression  as  specified  in  Table  6.3. 

6.4  OSAM* 

The  OSAM*  [SU89]  is  an  object-oriented  semantic  association  model  developed  at  the 
Database  Systems  Research  and  Development  Center  of  the  University  of  Florida.  The 
basic  structural  modeling  concepts  of  this  model  are  object  classes  (i.e.,  E-class  and  D- 
class)  and  associations  between/among  classes.  There  are  five  system-defined  association 
types  in  OSAM*  to  represent  different  object/class  relationships.  They  are  aggregation  (A), 
generalization  (G),  interaction  (I),  composition  (C),  and  cross-product  (X)  associations. 
The  A-association  is  similar  to  the  attribute  of  EXPRESS,  the  attribute  and  connection 
relationship  of  JDEF-1X,  and  the  BRIDGE  (connecting  one  LOT  and  one  NOLOT)  and  the 
IDEA  (connecting  two  NOLOTs)  of  NIAM.  The  G-association  is  identical  to  the  supertype- 
subtype  relation  of  these  models  except  a  few  different  optional  constraints.  The  I- 
association  is  a  special  association  which  models  the  interactions  among  a  set  of  entity 
classes  and  is  similar  to  the  relationship  construct  of  the  ER  model.  For  example,  the 
interactions  among  Student,  Instructor,  and  Course  classes  can  be  modeled  as  objects  of 
another  class  called  Registration.  In  the  construct  shown  in  O-C-15  of  Table  6.4,  the  entity 
class  X  is  defined  by  an  interaction  among  a  number  of  classes  including  class  Y.  Z  is  an 
optional  name  of  the  association  between  X  and  Y.  Three  macros  are  needed  for  specifying 
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the  constraints  between  X  and  Y  or  X  and  any  other  constituent  class.  The  first  macro 
represents  a  total  participation  constraint  so  that  every  X  instance  is  existence  dependent  on 
each  of  its  constituent  class'  instances.  (It  is  not  meaningful  to  record  an  interaction  among 
some  objects  if  they  do  not  exist  as  members  of  their  corresponding  classes.)  The  second 


Table  6.4.  Examples  of  OSAM*  construct  and  constraint  patterns. 


NO. 

Pattern 

Macro  ReDresentation 

O-C-15 

PT(  X,  -,  count(X),  count(X),  (Z,  Y,  - ) ) 
PT(  Y,  -,    0,  count(Y),  (Z  ;1X,  - ) ) 
CD((-),  (X,  -),  (Z,Y,  -),  1.M.1.1  ) 

O-T-15-1 

TP 

I 

PT(  X,  -,  count(X),  count(X),  (Z,  Y,  - ) ) 
PT(  Y,  -,  count(Y),  count(Y),  (Z  \  X,  - ) ) 
CD((-),  (X, -),  (Z,  Y, -),  1,  M,  1, 1  ) 

Y 

O-T-15-2 

I     *  I 
Z1/SZ2 

[p1- q1JxC_J>s^p2' q2] 

CD((Z1 ,  Y1 ,  -),  (X,  -),  (72,  Y2,  -),  p1 ,  q1 ,  p2,  q2  ) 

Y1 

Y2 

O-C-16 

MB(  X,  system-named,  -,  SET,  ENTITYOBJECT, 

Px,  - )  where 
Px  =  (exist  x  in  (x:X  where  x  =  lnstance(Y1)))  AND 
AND 

(exist  x  in  (x:X  where  x  =  Instance(Yn))) 

X 

c 

Y1   

Yn 

macro  is  a  partial  participation  because  not  every  Y  instance  has  to  be  interacted  with 
instances  of  other  classes.  The  cardinality  mapping  between  X  and  Y  is  many-to-one  (i.e., 
a  Y  instance  can  participate  in  many  interactions  with  the  object  instances  of  other 
constituent  classes)  as  captured  by  the  Cardinality  (CD)  macro.  If  all  Y  instances  have  to 
participate  in  some  interactions  with  other  instances  as  defined  by  instances  of  X,  then  a 
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key  word  "TP"  is  specified  above  the  class  Y  (see  O-T-15-l)  and  the  second  Participation 
macro  of  O-C-15  will  be  replaced  by  a  total  participation  macro.  An  important  characteristic 
of  the  I-association  is  that  an  indirect  cardinality  mapping  constraint  can  be  added  for  a  pair 
of  interacting  classes.  As  shown  in  O-T-15-2,  the  indirect  mapping  between  Yl  and  Y2  is 
[pi,  ql]-to-[p2,  q2],  that  is,  every  Yl  instance  can  participate  in  interactions  with  at  least 
p2  and  at  most  q2  of  Y2  instances,  and  every  Y2  instance  can  participate  in  interactions 
with  at  least  pi  and  at  most  ql  of  Yl  instances.  To  represent  this  indirect  mapping 
constraint  in  ORECOM,  an  inter-association  Cardinality  (CD)  macro  is  used.  Note  that,  in 
this  construct,  the  constraints  of  each  individual  pair  (X  and  one  of  its  constituent  classes) 
is  supposed  to  be  captured  by  constructs  of  O-C-15  or  O-T-15-l. 

The  last  example  OSAM*  construct  in  Table  6.4  (i.e.,  O-C-16)  is  particularly  useful 
for  statistical  database  applications.  This  construct  represents  a  Composition  or  C- 
association.  It  means  that  the  dynamic  sets  of  objects  in  classes  Yl,  Y2,  ....Yn  are 
instances  of  X.  Any  attribute  (usually  statistical  summary  attribute)  of  class  X  (defined  by 
an  aggregation  association  not  shown  in  O-C-16)  would  characterize  the  set-structured 
instances  rather  than  the  individual  members  in  the  sets.  As  a  consequence,  the 
Membership  (MB)  macro  representation  of  this  construct  shows  that  X  is  a  system-named 
class,  its  structure  is  SET  and  its  class  type  is  ENTITY_OBJECT  where 
ENTITY_OBJECT  is  a  system-defined  class  of  all  entity  objects  of  a  database.  The 
constraint  on  the  members  of  X  is  that  each  member  of  X  corresponds  to  the  entire  set  of 
instances  of  Yi  for  i  =  l..n.  Here,  Instance(Yi)  denotes  the  entire  set  of  instances  of  Yi. 


CHAPTER  7 

THE  DATA  MODEL  AND  SCHEMA  TRANSLATION  SYSTEM 


In  order  to  achieve  the  interoperability  of  heterogeneous  database  systems,  a 
semantic-preserving  translation  of  the  modeling  constructs  and  constraints  captured  by 
different  data  models  and  defined  in  different  schemata  is  a  necessity.  In  the  previous 
chapters,  we  have  introduced  the  technique  of  data  model  analysis  which  is  based  on  the 
principle  of  semantic  decomposition  using  the  developed  core  model  ORECOM.  This  work 
provides  us  a  framework  for  the  development  of  a  semantic-preserving  schema  translation 
system  for  the  translation  of  schemata  defined  in  EXPRESS,  IDEF-1X,  NIAM,  and 
OSAM*.  This  chapter  describes  the  translation  process  and  the  architecture  of  such  a 
system. 

7.1  System  Overview 

The  objective  of  a  heterogeneous  schema  translation  system  is  to  translate  a  source 
schema  of  one  data  model  to  an  equivalent  target  schema  of  another  data  model.  Since  a 
schema  is  defined  in  terms  of  the  modeling  constructs  and  constraints  of  its  underlying  data 
model,  the  translation  between  schemata  will  need  information  about  the  equivalence 
relationships  between  the  modeling  constructs  and  constraints  of  the  source  and  the  target 
data  models.  The  ORECOM-based  translation  system  therefore  consists  of  two 
subsystems.  A  data  model  translation  subsystem  provides  the  equivalence  relationships  for 
each  pair  of  data  models  and  the  schema  translation  subsystem  uses  the  equivalence 
information  to  perform  the  translation  of  schemata. 
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7.1.1  Subsystem- 1 :  Data  Model  Translation 

The  analysis  of  data  models  to  establish  their  equivalences  and  discrepancies 
consists  of  the  following  three  steps: 

•  Step  1:  Identify  the  basic  modeling  constructs  and  their  associated  constraints  of  both  the 

source  and  target  data  models.  Each  identified  construct  and  its  constraints  is 
represented  as  a  syntatical  or  graphical  pattern  and  is  labeled  with  a  pattern  index. 
(Data  model  analysis) 

•  Step  2:  Determine  the  macro  and  micro-rule  representations  of  each  pattern  identified  in 

Step  1.  (Decomposition) 

•  Step  3:  Based  on  the  macro  representations  of  source  and  target  patterns,  determine  their 

equivalences  and  discrepancies.  (Equivalence  analysis) 

These  steps  are  carried  out  by  persons  who  are  knowledgable  with  the  data  models  being 
considered.  As  illustrated  by  Figure  7.1,  two  models  are  individually  processed  in  Step  1 
to  Step  2.  The  results  are  two  sets  of  patterns  and  their  macro  and  micro-rule 
representations,  which  are  stored  as  the  matadata  of  the  pair  of  processed  models.  Then,  an 
equivalence  analysis  is  carried  out  using  their  macro  representations  to  derive  their 
equivalence  relationships.  The  output  of  the  equivalence  analysis  is  an  equivalence  matrix 
with  its  rows  and  columns  representing  the  source  and  target  patterns,  respectively.  Each 
non-empty  element  of  the  matrix  is  called  an  adjustment  factor  which  specifies  the 
discrepancy  (in  terms  of  macros)  between  a  source  pattern  and  the  closest  pattern  that  can 
be  found  in  the  target  model.  If  two  patterns  are  equivalent,  the  corresponding  matrix 
element  will  be  marked  by  an  equal  sign  (=).  As  an  example,  let  us  consider  the  patterns 
indexed  as  AC1  of  model  A  and  BC5  of  model  B  in  Figure  7.1.  AC1  is  assumed  to  be 
decomposed  into  three  macros,  Ml,  M2  and  M3,  and  BC5  is  decomposed  into  Ml  and 
M2.  If  BC5  is  the  closest  construct  of  model  B  to  AC1,  then,  to  make  these  two  patterns 
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equivalent,  the  macro  M3  has  to  be  added  to  BC5  as  the  adjustment  factor.  That  is,  "AC1  = 
BC5  +  M3".  We  note  that,  although  we  are  using  an  equivalence  matrix  for  the  mapping  of 
each  pair  of  data  models,  this  approach  is  different  from  the  direct  translation  approach 
discussed  in  Chapter  2  since  the  schema  translation  method  (see  Section  7.1.2)  is  separated 
from  the  data  (i.e.,  the  equivalent  information  provided  by  the  matrices)  which  drive  the 
translation  process.  In  other  words,  our  schema  translation  method  is  general  in  the  sense 
that  it  is  independent  of  the  source  and  target  models.  Only  the  equivalence  matrices  are 
specific  to  pairs  of  data  models. 


Source  Data  Model :  A 

Constructs 

Constraints 

Data  Model  Analysii 
&  Decomposition 

Target  Data  Model :  B 

Constructs 

Constraints 

Data  Model  Analysis 
&  Decomposition 

Construct/ 
Constraint 

AC1 

Construct/ 
Constraint 

BC5 

Macros 

M1 

M2 

M3 

Macros 

M1 

M2 

MicroRules 

R1 

R4 

R2 

R3 

R4 

R5 

MicroRules 

R1 

R4 

R2 

Adjustment 
Factor 


Figure  7.1  Data  model  translation. 


To  translate  any  pair  of  data  models  of  EXPRESS,  EDEF-1X,  NIAM,  and  OSAM*, 
twelve  equivalence  matrices  are  needed,  which  have  been  manually  analyzed  and  their 
results  are  included  in  the  APPENDIX  C  of  this  dissertation. 
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7.1.2  Subsystem-2:  Schema  Translation 

Schema  translation  is  driven  by  the  equivalence  information  generated  by 
subsystem- 1.  Given  a  source  schema,  its  equivalent  target  schema  defined  in  a  different 
data  model  is  generated  by  the  following  three  steps: 

•  Step  1:  Based  on  the  syntax  of  the  data  definition  language  (textual  or  graphical)  of  the 

source  data  model,  compile  the  input  schema  into  a  set  of  basic  patterns  of 
constructs  and  their  constraints  which  have  been  identified  in  Step  1  of 
subsystem- 1.  (Schema  compilation) 

•  Step  2:  For  each  pattern  of  the  input  schema,  search  the  equivalence  matrix  of  subsystem- 

1  for  an  equivalent  pattern  of  the  target  data  model.  (Equivalence  search) 

•  Step  3:  Collect  all  searched  patterns  of  the  target  data  model  and  generate  the  target 

schema.  If  there  are  discrepancies  found  in  Step  2,  they  are  used  to  either  generate 
an  explanation  to  the  user  so  that  he/she  can  take  care  of  the  discrepancies  in 
his/her  application  development  using  the  target  schema,  or  generate  program 
codes  to  be  incorporated  into  the  user's  application  system.  The  automatic 
generation  of  explanations  and  programs  is  possible  since  the  semantics  of  the 
discrepancies  have  been  explicitly  defined  by  macros  and  micro-rules  which 
define  the  trigger  conditions  and  database  operation  in  great  details.  (Schema 
generation)  £ 

The  overall  procedure  of  a  schema  translation  is  illustrated  by  Figure  7.2. 
Subsystem-2  has  an  optional  input  specifying  the  additional  constraints  which  are  to  be 
added  to  the  source  schema.  The  added  constraints  are  the  semantic  properties  of  the 
applications  that  were  not  modeled  in  the  source  schema3  but  the  user  wants  them  to  be 
incorporated  in  the  target  schema.  These  added  constraints  can  be  specified  in  either 

3Some  added  constraints  may  be  extracted  from  the  code  embedded  in  application  programs 
or  method  implementations  of  an  object-oriented  model  or  in  the  rule  specification  block  of 
a  schema  defined  in  a  data  model  like  EXPRESS.  Or  it  can  be  obtained  directly  from  the 
original  schema  designer  or  the  schema  translation  administrator. 
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ORECOM  macros  or  in  some  rule  specification  language.  In  the  latter  case,  the 
specification  needs  to  be  translated  into  macros  which  can  then  be  merged  with  the 
compiled  source  schema  for  translation  into  the  target  schema. 
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Figure  7.2  Schema  translation. 


7.2  System  Architecture 

Combining  the  above  two  subsystems,  the  architecture  of  a  data  model  and  schema 
translation  system  is  shown  in  Figure  7.3.  Subsystem- 1  contains  two  major  processing 
steps  (i.e.,  semantic  analysis  and  equivalence  analysis)  and  a  database  to  store  the 
macro/micro-rule  definitions,  decomposed  data  model  patterns,  and  equivalence  matrices. 
Semantic  analysis  is  a  manual  process  which  carries  out  the  tasks  of  Step  1  and  Step  2  of 
subsystem- 1.  For  each  data  model,  its  semantics  is  analyzed  and  the  result  (i.e., 
decomposed  patterns  with  macro  representation)  is  stored  for  use  in  the  equivalence 
analysis.  During  a  semantic  analysis,  the  stored  macro  definitions  (and  their  micro-rules) 
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Figure  7.3  Architecture  of  the  data  model  and  schema  translation  system. 
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can  be  accessed  by  the  human  analyzer  to  aid  his/her  analysis.  Additional  micro-rules  or 
macros  can  be  defined  by  the  analyzer  to  extend  the  system's  capability  to  capture  new 
semantic  properties.  The  equivalence  analysis  step  performs  the  manual  task  stated  in  Step 
3  of  subsystem- 1  to  generate  an  equivalence  matrix  for  a  given  pair  of  source  and  target 
data  models.  This  analysis  is  intended  to  be  a  general  process  by  taking  advantage  of  the 
neutral  representation  of  each  model  so  that  the  equivalence  relationships  between  a  source 
and  a  target  model  can  be  derived  without  referring  to  their  original  representations. 
Basically,  it  functions  as  a  pattern  matching  process  by  looking  into  the  macro 
representation  of  every  target  pattern  to  find  out  the  closest  one  to  the  given  source  pattern. 
Subsystem-2  is  an  automated  system.  It  has  three  sets  of  working  modules.  The  first  set 
forms  the  front-end  interface  which  contains  schema  compilers  and  rule  translators  to 
execute  the  tasks  specified  in  Step  1  of  schema  translation.  There  are  as  many  schema 
compilers  and  rule  translators  as  the  number  of  data  models  handled  by  the  translation 
system.  The  second  set  contains  only  a  single  module  which  carries  out  the  equivalence 
search  (i.e.,  Step  2  of  subsystem-2.)  It  takes  the  merged  output  of  the  schema  compiler  and 
rule  translator  and  make  use  of  the  equivalence  matrix  to  map  the  source  patterns  of 
constructs  and  constraints  to  the  target  patterns  and  possibly  a  list  of  macros  which 
represent  the  discrepancies  between  the  two  schemata.  The  third  set  of  modules  is 
composed  of  schema  generators  and  rule  translators.  A  schema  generator  does  exactly  the 
reverse  task  of  a  schema  compiler.  It  generates  the  target  schema  using  the  set  of  target 
patterns.  Similarly,  a  rule  translator  translates  the  discrepancies  expressed  in  macros  to 
some  representation  such  as  plain  English  statements,  rules  of  a  particular  constraint 
language,  or  programs  of  some  programming  language. 

7.3  An  Example  of  OSAM*  to  IDEF-1X  Schema  Translation 

In  this  section,  we  use  an  example  of  translating  an  OSAM*  schema  to  its 
equivalent  IDEF-1X  schema  to  illustrate  the  translation  process  performed  by  the  system 
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presented  in  the  last  section.  The  source  schema  is  defined  in  OSAM*  and  is  shown  in 
Figure  7.4.  This  schema  models  the  interaction  between  STUDENT  and  COURSE 
classes,  which  is  modeled  as  another  E-class,  REGISTRATION,  using  the  I-association. 
These  three  classes  have  their  own  user-defined  keys  (i.e.,  S#,  C#,  and  R#,  respectively) 
all  of  which  have  INTEGER  as  their  domain  class.  The  REGISTRATION  class  has  an 
optional  but  one-to-one  attribute  named  ProcessedBy,  which  is  defined  on  another  D-class 
STRING.  The  semantics  of  this  schema  is  that  each  REGISTRATION  object  represents  a 
particular  registration  made  by  a  single  student  on  a  single  course,  but  a  student  can  register 
many  courses  and  a  course  can  be  registered  by  many  students.  Besides  this  general 
semantics,  there  are  two  additional  constraints:  (1)  the  symbol  "TP"  along  the  COURSE 
specifies  that  every  course  must  be  registered  by  some  student(s),  and  (2)  the  indirect 
mapping  of  "STUDENT  :  COURSE"  is  "[7,  120]  :  [1,  5]",  meaning  a  student  can  register 
at  most  five  courses  and  a  course  must  be  registered  by  at  least  seven  and  at  most  120 
students. 


Figure  7.4  A  source  schema  of  OSAM*. 


85 


The  translation  starts  with  the  OSAM*  schema  compiler  which  reads  and  compiles 
the  source  schema  into  a  number  of  OSAM*  pattern  types  shown  in  Figure  7.5.  Each 
pattern  type  has  a  list  of  instances  each  of  which  contains  class  or  attribute  names  defined  in 
the  schema  that  form  the  pattern  instance.  A  pair  of  braces  ("{}")  is  used  to  enclose  a 
pattern  instance.  For  example,  the  first  pattern  O-C-06  in  Figure  7.5  specifies  that  the  three 
classes  STUDENT,  COURSE,  and  REGISTRATION  satisfy  this  pattern  type  which 
denotes  all  E-classes. 


O-C-06       [  {STUDENT,  (S#)} 
{COURSE,  (C#)} 
{REGISTE RATION,  (R#)}  ] 

O-T-1 1-3     [  {REGISTERATION,  ProcessedBy,  STRING}  ] 

O-T-1112-4  [{STUDENT,  (S#,  INTEGER)} 
{COURSE,  (C#,  INTEGER)} 
{REGISTERATION,  (R#,  INTEGER)}  ] 

O-C-15    [  {REGISTERATION,  RequestedBy  STUDENT} 
{REGISTERATION,  Title,  COURSE}  ] 

O-T-1 5-1  [  {REGISTERATION,  Title,  COURSE}  ] 

O-T-1 5-2  [  {REGISTERATION,  ((RequestedBy,  STUDENT),  (Title,  COURSE)),  7,  120,  1,  5  }  ] 


Figure  7.5  The  OSAM*  source  schema  after  compilation. 


The  list  of  OSAM*  schema  pattern  types  is  then  processed  by  the  equivalence 
search  module  to  map  them  into  a  list  of  pattern  types  of  the  target  model  (IDEF-1X).  Here, 
the  equivalence  matrix  of  OSAM*-to-IDEF-lX  generated  by  the  subsystem- 1  is  used  for 
this  purpose.  A  part  of  this  matrix  is  shown  in  the  table  of  Figure  7.6.  In  this  table,  most 
OSAM*  patterns  have  an  equivalent  IDEF-1X  pattern  except  O-T-1 1-3  and  O-T-15-2.  The 
pattern  O-T-1 1-3  captures  the  constraint  of  an  optional  attribute  with  an  one-to-one 
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cardinality  constraint  whose  closest  pattern  in  IDEF-1X  is  I-C-04  (see  Figure  6.1  or 
APPENDIX  B.l).  In  order  to  preserve  the  semantics  in  this  translation,  Cardinality  (CD) 
macros  need  to  be  added  and  substracted.  For  O-T-15-2,  which  specifies  the  indirect 
mapping  constraint  of  the  OSAM*'s  I-association,  no  corresponding  pattern  exists  in 
IDEF-1X.  Therefore,  it  becomes  a  discrepancy  between  these  two  models.  For  those 
OS  AM*  patterns,  which  have  equivalent  IDEF-1X  patterns,  their  associated  values  are 
copied  to  instantiate  the  IDEF-1X  patterns  as  shown  in  Figure  7.7. 
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Figure  7.6  Part  of  the  equivalence  matrix  for  translating  OSAM*  to  IDEF-1X. 


The  last  step  of  the  translation  is  to  generate  the  target  schema  from  the  list  of 
instantiated  IDEF-1X  pattern  types.  The  IDEF-1X  schema  generator  first  parses  the  list  of 
patterns  into  its  internal  dictionary  and  then  composes  and  displays  the  target  schema.  All 
discrepancies  in  terms  of  the  adjusted  macros  are  also  displayed  with  the  target  schema. 
The  IDEF-1X  target  schema  is  shown  by  the  diagram  of  Figure  7.8.  (In  this  target  schema, 
we  have  assumed  the  two  verb  phrases  'IsTitleOf  and  'Registers'  are  the  inverse  of 
attributes  'Title'  and  'RequestedBy',  respectively.) 
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l-C-01      [  {STUDENT,  (S#)} 
{COURSE,  (C#)} 
{REGISTERATION,  (R#)}] 

l-C-04      [  {REGISTERATION,  (ProcessedBy,  STRING)}  ] 

l-T-04-2   [  {STUDENT,  (S#,  INTEGER)} 
{COURSE,  (C#,  INTEGER)} 
{REGISTERATION,  (R#,  INTEGER)}  ] 

l-T-05-1    [  {REGISTERATION,  (RequestedBy,  STUDENT)}] 

l-T-06-1    [  {REGISTERATION,  (Title,  COURSE)}  ] 


-  CD  ((-),  (REGISTRATION,  -),  (ProcessedBy,  String,  -),  1, 1, 1, 1  ) 
+  CD  ((-),  (REGISTRATION,  -),  (ProcessedBy,  String,  -),  1,  M,  1, 1 ) 
+  CD  ((RequestedBy,  STUDENT,  -),  (REGISTRATION,  -),  (Title,  COURSE,  -),  7,  120,  1,  5  ) 


Figure  7.7  The  search  module  output  for  generating  an  IDEF-1X  target  schema. 


STUDENT 


COURSE 


C# 


Registers 
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REGISTRATION 


-  CD  ((-),  (REGISTRATION,  -),  (ProcessedBy,  String,  -),  1,  1,1,1) 

+  CD  ((-),  (REGISTRATION,  -),  (ProcessedBy,  String,  -),  1,  M,  1,  1 ) 

+  CD  ((RequestedBy,  STUDENT,  -),  (REGISTRATION,  -),  (Title,  COURSE,  -),  7,  120,  1  5  ) 


Figure  7.8  The  generated  equivalent  IDEF-1X  target  schema  with  the  discrepancies. 
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7.4  System  Implementation 

The  implementation  of  the  data  model  and  schema  translation  system  started  in  1990 
at  the  Database  Systems  R&D  Center  of  the  University  of  Florida.  Six  Masters  students 
have  collaborated  in  this  project  to  develop  the  schema  translation  subsystem,  including 
four  pairs  of  schema  compilers  and  generators  and  one  equivalence  search  module.  A 
prototype  system  which  can  translate  schemata  of  any  pair  (in  either  direction)  of  the  four 
data  models  (EXPRESS,  IDEF-1X,  NIAM,  and  OSAM*)  has  been  completed.  This 
prototype  is  implemented  in  C  running  on  both  UNIX-based  Sun  workstations  and  AIX- 
based  IBM  RS-6000  workstations.  The  schema  translation  system  is  featured  by  its 
graphical  user  interface  (GUI)  implemented  in  an  X-Window  environment  using 
OSF/Motif  widget  set.  Although  the  subsystem- 1  can  also  be  implemented  to  automatically 
translate  data  models,  we  have  not  done  so  at  this  stage.  We  have,  however,  manually 
converted  the  modeling  constructs  and  constraints  into  their  ORECOM  representations 
(i.e.,  data  model  pattern  types)  and  derived  the  pair-wise  equivalence  matrices  for  all  the 
combinations  of  the  above  four  models  to  support  the  schema  translation  (see  APPENDIX 
C).  The  prototype  system  has  been  demonstrated  at  RPI,  NIST  and  IBM  Kingston  in  May 
1992  and  the  second  annual  EXPRESS  User's  Group  (EUG'92)  at  Texas  in  October  1992. 

In  this  prototype  system,  a  schema  compiler  and  a  schema  generator  are 
implemented  for  each  of  the  four  data  models.  Particularly,  for  IDEF-1X,  both  graphical 
and  textual  interfaces  have  been  implemented  so  that  an  IDEF-1X  schema  can  be  processed 
(input  and  output)  in  either  format:  diagrammatically  [GAR91]  or  in  its  textual  language 
called  SML.  EXPRESS  has  an  official  graphic  representation  called  EXPRESS-G,  but  it 
only  supports  a  subset  of  EXPRESS.  The  schema  translation  project  is  currently  involved 
in  developing  a  graphics-based  EXPRESS  toolset  including  an  EXPRESS-G  editor,  a 
browser,  and  a  query  processor.  In  addition,  an  EXPRESS  schema  compiler  [CHE91]  and 
a  generator  were  implemented  for  the  old  version  of  EXPRESS  (ISO  TC184/SC4/WG5, 


89 


N14,  1989).  They  have  been  upgraded  to  the  new  version  released  in  August  1992 
(N151).  For  NIAM,  only  a  textual  interface  (schema  compiler  and  generator)  has  been 
implemented  [UPP93].  It  is  based  on  a  constraint  language  of  NIAM,  called  RIDL 
[NIE88].  The  OS  AM*  schema  compiler  and  generator  are  adopted  from  the 
OSAM*. KBMS  project  [SRE93]. 

The  equivalence  search  module  of  the  schema  translation  subsystem  has  also  been 
implemented.  A  future  plan  for  this  module  is  to  enhance  its  capability  so  that  it  can  accept 
macros  directly  from  the  system  input  and  merge  them  with  the  compiled  source  schema. 
The  implementation  of  the  two  rule  translators  are  yet  to  be  carried  out.  In  the  absence  of 
these  rule  translators,  the  present  system  allows  additional  constraints  to  be  inputted  in 
terms  of  ORECOM  macros  and  the  discrepancies  found  in  a  translation  are  presented  to  the 
user  in  macros  and  micro-rules  without  interpretation. 

7.5  Applications 

The  above  presented  data  model  and  schema  translation  system  provides  a  general 
framework  for  resolving  the  data  model  heterogeneity  problem  found  in  multimodel 
database  systems.  Many  problems  associated  with  the  interoperability  of  multimodel 
database  systems  such  as  data  model  learning,  schema  integration,  and  schema  verification 
and  optimization  can  also  be  benefited  from  the  system  and  its  semantic  decomposition 
technique. 

7.5.1  Data  Model  Learning 

One  possible  application  of  ORECOM  is  to  assist  a  user  or  a  database  system 
designer  or  developer  in  learning  the  semantics  of  a  new  data  model  in  two  ways.  First, 
when  a  data  model  is  mapped  to  an  ORECOM  representation,  each  of  its  modeling 
constructs  and  its  associated  constraints  are  fully  decomposed  (as  presented  in  the  previous 
sections)  into  a  concise  parameterized  representation  (i.e.,  the  macro  representation)  and  its 
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corresponding  operational  semantics  (i.e.,  the  micro-rule  representation).  A  user  can  learn 
quite  easily  the  modeling  concepts  of  a  new  data  model  from  the  macro  representations  of 
its  constructs  and  a  system  designer  or  developer  can  gain  precise  information  about  the 
DBMS  operations  needed  to  implement  a  construct  or  enforce  a  constraint  from  its  micro- 
rule  representation.  This  information  is  useful  in  designing  a  schema,  implementing  a 
database,  or  writing  a  control  or  interface  program.  Second,  since  different  data  models  can 
be  mapped  to  the  neutral  ORECOM  representation,  the  data  model  learning  process  can  be 
considerably  eased  by  comparing  the  neutral  representation  of  a  new  construct  or  constraint 
with  that  of  the  corresponding  construct  or  constraint  in  a  model  familiar  to  the  user.  Due  to 
the  neutral  representation  of  all  decomposed  modeling  constructs  and  constraints,  a  cross 
reference  between  a  new  model  and  a  well-understood  model  can  be  automatically 
generated  to  compare  their  commonalties  and  differences. 

7.5.2  Schema  Integration 

In  a  multimodel  database  system  environment,  schema  integration  is  a  necessary 
task  in  the  development  of  a  federated  or  integrated  database  management  system.  A 
desirable  approach  to  schema  integration  is  to  first  translate  heterogeneous  schemata  into 
common  representations  and  then  integrate  them.  This  approach  is  used  in  the  work 
reported  in  [SPA92].  The  use  of  ORECOM  as  the  neutral  model  has  the  following  benefits: 

1)  the  integration  can  be  carried  out  on  the  basis  of  macros  whose  low-level  and  primitive 
representations  can  distinguish  the  fine  semantic  differences  of  different  modeling 
constructs  and  constraints  which  can  not  be  distinguished  by  a  high-level  common  model, 

2)  a  tightly  integrated  global  schema  can  be  generated  to  capture  not  only  the  structures  but 
also  the  constraints  and  operations  of  the  component  schemata,  3)  the  mapping  relationship 
between  the  global  and  the  component  schemata  can  be  recorded  and  reported  in  detail  (in 
terms  of  macros  or  micro-rules)  for  interfacing  the  global  and  local  query  and  transaction 
processes. 
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7.5.3  Schema  Verification  and  Optimization 

The  existing  tools  for  checking  the  correctness  of  a  schema  (i.e.,  verification)  and 
for  removing  the  redundant  constructs  or  constraints  from  a  schema  (i.e.,  optimization)  are 
usually  data-model-dependent.  Using  ORECOM  as  a  neutral  model,  the  development  of  a 
common  schema  management  tool  for  these  two  tasks  is  possible  because  heterogeneous 
schemata  can  be  translated  into  the  primitive  ORECOM  representations  before  applying 
verification  and  optimization  techniques  on  them. 


CHAPTER  8 
CONCLUSIONS 


In  this  dissertation,  we  have  described  the  design  and  development  of  a  data  model 
and  schema  translation  system.  The  underlying  core  data  model,  the  semantic 
decomposition  technique,  the  translation  methodology,  and  the  implementation  architecture 
of  the  system  have  been  presented.  The  development  of  the  translation  system  is  based 
upon  the  following  two  basic  principles.  First,  a  neutral  data  model  is  used  as  the 
intermediate  representation  in  data  model  and  schema  translations  to  reduce  the  complexity 
and  to  avoid  a  large  number  of  pair-wise  direct  translations.  Second,  high-level  modeling 
constructs  and  constraints  are  decomposed  into  some  low-level,  neutral,  primitive  semantic 
representations  so  that  the  equivalence  relationship  between  different  constructs  and 
constraints  of  different  data  models  can  be  determined  precisely  and  specified  explicitly. 

We  have  presented  ORECOM  as  the  neutral  representation  to  facilitate  the  semantic 
decomposition  of  high-level  data  models.  Different  from  those  semantically-rich  data 
models  which  provide  high-level  structural  constructs  and  constraints,  ORECOM  is  a  low- 
level  data  model  consisting  of  a  number  of  modeling  primitives,  i.e.,  objects,  classes, 
associations,  object  operations,  micro-rules,  and  macros.  High-level  structural  constructs 
and  constraints  are  decomposed  into  ORECOM's  modeling  primitives.  For  the  convenience 
of  data  model  and  schema  translations,  we  have  defined  eight  macros  and  their  semantics 
using  the  powerful  knowledge  rule  specification  language  K  to  represent  the  eight  basic 
constraint  types  found  in  many  existing  data  models.  Due  to  their  compact  and  uniform 
representations,  the  process  of  semantic  decomposition  is  made  simpler.  The  analysis  of 
these  constraint  types  is  based  on  our  study  of  the  semantic  properties  of  modeling 
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constructs  and  constraints  found  in  several  semantically-rich  data  models  including  IDEF- 
IX,  EXPRESS,  NIAM,  and  OSAM* 

To  verify  our  semantic  analysis  of  data  models,  the  technique  of  semantic 
decomposition  and  the  utility  of  the  neutral  core  model  ORECOM  for  schema  translation, 
we  have  developed  a  schema  translation  system  which  is  capable  of  translating  schemata 
defined  in  IDEF-1X,  EXPRESS,  NIAM,  and  OSAM*  models.  The  translation  of  high- 
level  constructs  and  constraints  to  ORECOM  representations,  the  matching  and 
transformation  of  the  ORECOM  representations  of  one  model  to  that  of  another,  and  the 
generation  of  target  schemata  have  been  described  in  this  dissertation.  Other  applications  of 
the  neutral  model  in  addition  to  schema  translation  have  also  been  presented. 

We  shall  in  the  following  summarize  the  contributions  of  this  research  effort  and 
provide  the  direction  for  future  work. 

8.1  The  Contributions  of  the  Research 

One  of  the  major  contributions  of  our  research  is  the  development  of  the  Object- 
oriented  Rule-based  Extensible  Core  Model  (ORECOM)  and  the  formalization  of  its  general 
semantic  constraint  types.  It  has  been  shown  that,  by  using  ORECOM's  modeling 
primitives  as  the  neutral  representation,  the  semantics  captured  by  many  different  data 
models  can  be  evaluated  and  decomposed.  By  comparing  the  primitive  representations  of 
the  decomposed  constructs  and  constraints,  we  are  able  to  identify  whether  these  constructs 
and  constraints  are  identical,  slightly  different,  or  totally  unrelated.  In  case  of  non-identical 
constructs  and  constraints,  the  discrepancies  between  them  can  be  explicitly  specified  by 
the  primitive  representations  and  be  used  in  an  application  development  to  account  for  the 
missing  semantics.  Semantic  decomposition  of  high-level  data  models  to  ORECOM 
representations  will  be  very  useful  for  (i)  verifying  a  data  model  to  see  if  the  semantics  of 
its  constructs  and  constraints  are  defined  consistently,  (ii)  learning  a  new  data  model  by 
comparing  its  primitive  representation  with  those  of  others  familiar  to  the  user,  and  (iii) 
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evaluating  a  set  of  different  data  models  (e.g.,  compare  their  semantic  properties,  and 
measure  their  modeling  capabilities)  to  aid  the  development  of  a  multi-model  heterogeneous 
database  system.  It  should  be  noted  that  the  technique  of  semantic  decomposition  using 
ORECOM  is  not  limited  to  the  set  of  data  models  that  we  have  examined.  The  same 
technique  can  be  applied  for  the  translations  of  other  data  models  and  schemata. 

To  this  end,  we  have  provided  a  general  and  open  framework  for  data  model 
analysis  and  conversion,  which  is  an  essential  step  to  achieve  the  interoperability  of 
heterogeneous  database  systems.  Future  researchers  who  want  to  study  the  semantics  of 
their  data  models  can  use  it  to  gain  a  better  understanding  of  their  models  and  to  relate  their 
own  models  to  the  existing  ones.  Our  analysis  of  the  four  data  models,  namely,  IDEF-1X, 
EXPRESS,  NIAM,  and  OS  AM*,  can  serve  as  an  excellent  basis  for  any  future  research  or 
application  that  involves  these  data  models. 

Another  contribution  of  this  research  is  the  design  and  development  of  the  data 
model  and  schema  translation  system.  The  implementation  of  this  system  is  the  result  of  a 
team  effort.  This  system  not  only  concretely  demonstrates  the  soundness  and  utility  of  the 
neutral  model  ORECOM  for  schema  translation,  but  also  can  serve  as  a  useful  tool  for 
schema  translation  in  a  multi-model  database  environment.  Using  this  system,  we  can 
create  a  schema  using  a  graphical  or  textual  editing  tool  for  any  of  the  data  models:  IDEF- 
IX,  EXPRESS,  NIAM,  and  OSAM*.  We  can  then  compile  it  into  ORECOM's 
representation  so  that  further  process  (e.g.,  semantic  verification,  schema  optimization,  or 
schema  translation)  can  be  done  at  the  neutral  level  before  the  transformed  representation  is 
used  to  generate  a  target  schema.  Schema  translation  is  an  essential  step  to  integrate 
applications  of  different  data  models  in  order  to  achieve  interoperability  among  these 
applications.  Manufacturing  industry  has  been  using  IDEF-1X,  NIAM  and  EXPRESS  very 
widely.  Presently,  the  international  community  on  standards,  PDES/STEP,  has  been 
working  on  a  data  model  standard  for  product  data  specification  and  exchange.  Many 
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industrial  companies  are  interested  in  converting  their  existing  schemata  of  products  to  the 
standard.  ORECOM  and  the  schema  translation  system  can  be  very  useful  for  this  purpose. 

To  sum  up,  the  neutral  data  model  ORECOM  and  the  schema  translation  system  not 
only  contribute  to  our  understanding  of  the  semantics  of  data  model  constructs  and 
constraints  but  also  provides  a  useful  system  for  solving  many  problems  related  to  the 
interoperability  of  multi-model  database  systems. 

8.2  Future  Research 

Some  additional  work  can  be  carried  out  based  on  the  work  accomplished.  The 
neutral  core  model  and  its  basic  constraint  types  can  be  extended  to  accommodate  new 
modeling  concepts  introduced  in  new  data  models  such  as  spatial  and  temporal  models.  The 
object-oriented  feature  of  ORECOM  would  allow  new  data  types  to  be  defined  for  temporal 
and  spatial  concepts  and  elements.  The  rule  specification  facility  of  ORECOM  would 
provide  the  added  capability  to  specify  the  semantics  of  these  new  data  types. 

Further  development  effort  can  be  taken  to  increase  the  capability  of  the  schema 
translation  system.  For  example,  there  are  many  legacy  systems  which  use  relational  and  E- 
R  models.  The  inclusion  of  these  models  in  the  schema  translation  system  will  allow  the 
existing  schemata  to  be  converted  into  schemata  defined  in  semantically-rich  data  models. 
Since  the  models,  based  on  which  our  model  analysis  have  been  carried  out,  are 
semantically  richer  than  the  conventional  models,  the  conversion  of  their  constructs  and 
constraints  to  ORECOM  representations  will  not  present  a  problem. 


APPENDIX  A 
DEFINITIONS  OF  MACROS 


A.l  MEMBERSHIP  (MB) 


MB  (  X ,  O ,  I,  S,  T,  C,  M  ) 


a  system-defined 
meta  class 


class  X  is  an  instance  of  CLASS 


an  entity  class 


ClassName 
ObjectType 
Identifier 
Structure 
ClassType 
Constraint 
^LocalOperation 


=  X  (class  name) 

=  O  (object  type) 

=  I  (user-defined  identifier) 

=  S  (object  structure) 

=  T  (class  type) 

=  C  (membership  constraints) 

=  M  (object  operations  or 
methods) 


or 


a  domain  class 


Rule 
Location 


Rule 


CLASS 


ruleMB-01  is 

triggered   immediate_after  this. CREATE 
action       this. ClassName  :=  X; 

this.ObjectType  :=  O; 

if  O  =  "system-named"  then  this. Identifier  :=  I; 

else  this.Identifier  := ""; 
end_if; 

this.Structure  :=  S; 
this. ClassType  :=  T; 
this. Constraint  :=  C; 
this.LocalOperation  :=  M; 
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A.2  PARTICIPATION  CPT) 


PT(X,  Px,  min,  max,  ((cc1,  Y1,  Py1 ),...,  (at,  Yt,  Pyt)) ) 


Py1 


There  must  be  at  least  'min',  at  most  'max'  of 

qualified  X  objects  associate  with  qualified  Y1  or 
..  or  Yt  objects. 


Y1 

Pyi 

Yi 

Pyt 

Yt 

rulePT-01  is 

triggered   after  this.CREATE,  immediate_after  this.DIS  ASSOCI  ATE(ai.yi)    i  =  1  ..t 
condition    Px(this)  AND  Pyi(yi) 

=>  exist  x  in  ((x:X  OR(*>al  Yl[Pyl], ....  *>  at  Yt[Pyt]))  where  Count(x)  <  min  ) 
action  REJECT; 

rulePT-02  is 

triggered    immediate_after  this.ASSOCIATE(ai,yi)  i=l..t 
condition    Px(this)  AND  Pyi(yi) 

=>  exist  x  in  ((x:X  OR(*>al  Yl[Pyl], *>  at  Yt[Pyt]))  where  Count(x)  >  max  ) 
action  REJECT; 

rulePT-03  is 

triggered   immediate_after  /*  any  ASSOCIATE  and  DISASSOCIATE  between  an  X  object  (this) 

and  any  object  of  an  associated  class  involved  in  Px  */ 

condition  Px(this) 

=>  exist  x  in  ((x:X  OR(*>al  Yl[Pyl], *>  at  Yt[Pyt]))  where  min  <  Count(x)  <  max ) 
otherwise  REJECT; 


Yi 


rulePT-04  is 

triggered  immediate_after  /*  any  ASSOCIATE  and  DISASSOCIATE  between  a  Yi  object  (this) 

and  any  object  of  an  associated  class  involved  in  Pyi  */ 
condition  Pyi(this)  AND  exist  x  in  (x:X  [Px]  *>ai  this) 

=>  exist  x  in  ((x:X  OR(*>al  Yl[Pyl], *>  at  Yt[Pyt]))  where  min  <  Count(x)  <  max ) 
otherwise  REJECT; 


rule  PT-05  is  /*  defined  in  a  class  Q  which  represents  any  one  of  the  classes  involved  in  Px  and 

having  an  association  with  another  involved  class  represented  by  Q'  */ 
triggered  immediate_after  /*  any  ASSOCIATE  and  DISASSOCIATE  between  a  Q  object  and 

a  Q'  object  */ 

condition  exist  x  in  x:X  [Px] 

=>  exist  x  in  ((x:X  OR(*>al  Yl[Pyl], *>  at  Yt[Pyt]))  where  min  <  Count(x)  <  max  ) 
otherwise  REJECT; 


Ri 


rule  PT-06  is  /*  defined  in  a  class  Ri  which  represents  any  one  of  the  classes  involved  in  Pyi  and 

having  an  association  with  another  involved  class  represented  by  Ri'  */ 
triggered  immediate_after  /*  any  ASSOCIATE  and  DISASSOCIATE  between  a  Ri  object  and 

a  Ri'  object  */ 
condition  exist  x,  yi  in  x:X  [Px]  *>ai  yi:Yi  [Pyi] 

=>  exist  x  in  ((x:X  OR(*>al  YI  [Py  1], *>  at  Yt[Pyt]))  where  min  <  Count(x)  <  max ) 
otherwise  REJECT; 
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A.3  CARDINALITY  (CD) 


CD  ( (((31,  Z1,  Pz1), ((3w,  Zw,  Pzw)),  ((X1,  Px1), (Xc,  Pxc)), 

((a1,  Y1,  Py1),      (at,  Yt,  Pyt)),  mini,  max1,  min2,  max2  ) 


Px1 

p 


X1 


Xc 


ai 


Pxc 


at 


Pz1 

Z1 

Zw 

Pzw  Py1 

Y1 

Yt 

Pyt 


(Zl, Zw)  :  (Yl, Yt)  =  [mini,  maxl]  :  [min2,  max2] 


X1 


ruleCD-01  is  triggered  immediate_after  this.ASSOCIATE(pi,  zi),  i=l..w 
condition  Px  1  (this)  AND  Pzi(zi) 

=>  {forall  zl,  ..,zi-l,zi+l,  ...zw  in  (this  AND(*>pi  zl:Zl[Pzl], ....  *>pi  zi, 

*>Pw  zw:Zw[Pzw]))  suchlhat  exist  yl, yt  in  (this  *>  X2[Px2]  *>  ...  *>  Xc[Pxc] 
AND(*>al  yl:Yl[Pyl], *>at  yt:Yt[Pyt])  where  min2  <  Count(yl, yt)  <  max2 ) 
AND 

{forall  yl, yt  in  (this  *>  X2[Px2]  *>  ...  *>  Xc[Pxc]  AND(*>al  yl:Yl[Pyl], 
*>at  yt:Yt[Pyt])  suchthat  exist  zl, zw  in  (this  AND(*>pi  zl:Zl[Pzl], 
*>Pw  zw:Zw[Pzw])  where  Count(zl, zw)  <  maxl  )  } 
otherwise  REJECT; 

ruIeCD-02  is  triggered  before  this.DISASSOCIATE(Pi,  zi),  i  =  l..w 
condition  Pxl(this)  AND  Pzi(zi) 

=>  forall  yl, yt  in  (this  *>  X2[Px2]  *>  ...  *>  Xc[Pxc]  AND(*>al  yl:Yl[Pyl], .... 
*>at  yt:Yt[Pyt])  suchthat  exist  zl, ....  zw  in 

(this  AND(*>pi  zl:Zl[Pzl], *>Pw  zw:Zw[Pzw])  where  Count(zl, zw)  =  mini  ) 
action  REJECT; 


Xc 


ruleCD-03  is   triggered  immediate_after  this.ASSOCIATE(ai,  yi),  i  =  l..t 
condition  Pxc(this)  AND  Pyi(yi) 

=>  (forall  yl, ..,  yi-1,  yi+1, ..,  yt  in  (this  AND(*>al  yl:Yl[Pyl]  *>ai  yi, .... 

*>at  yt:Yt[Pyt]))  suchlhat  exist  zl, zw  in 
(this  *>  Xc-l[Pxc-l]  *>  ...  *>  Xl[Pxl]  AND(*>pl  zl:Zl[Pzl], 
*>pw  Zw:Zw[Pzw])  where  mini  <  Count(zl, zw)  <  maxl ) } 
AND 

{forall  zl, zw  in  (this  *>  Xc-l[Pxc-l]  *>  ..  *>  Xl[Pxl]  AND(*>pi  zl:Zl[Pzl], ... 
*>Pw  zw:Zw[Pzw])  suchthat  exist  yl, ..,  yt  in  (this  AND(*>al  yl:Yl[Pyl], 
*>at  yt:Yt[Pyt])  where  Count(yl, ..,  yt)  <  max2 )} 
otherwise  REJECT; 

ruleCD-04  is   triggered  before  this.DISASSOCIATE(ai,  yi),  i  =  l..t 
condition  Pxc(this)  AND  Pyi(yi) 

=>  forall  zl  zw  in  (this  *>  Xc-l[Pxc-l]  *>  ..  *>  Xl[Pxl]  AND(*>pi  zl:Zl[Pzl]  

*>Pw  zw:Zw[Pzw])  suchthat  exist  yl, ..,  yt  in  (this  AND(*>cd  yl:Yl[Pyl], .... 

*>at  yt:Yt[Pyt])  where  Count(yl, ..,  yt)  =  min2 ) 
action  REJECT; 
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Xk 

rule  CD-05  is 

triggered   immediate_after  this.ASSOCIATE(-,  xk+1),  this.DIS ASSOCIATE(-,  xk+1), 
k=  l.x-1 

condition  Pxk(this)  AND  Pxk+ 1  (xk+ 1 ) 

=>  {forall  yl, yt  in  (xl:Xl[Pxl]  *>  ...  *>  this  *>  xk+1  *>...  *>  Xc[Pxc] 
AND(*>od  yl:Yl[Pyl], *>at  yt:Yt[Pyt])  suchthat  exist  zl, zw  in 
( xl  AND(*>pi  zl:Zl[Pzl], *>pw  zw:Zw[Pzw]) 
where  mini  <  Count(zl, zw)  <  maxl )  } 
AND 

{forall  zl, ....  zw  in  (xc:Xc[Pxc]  *>  ..  *>  zk+1  *>  this  *>..  *>  Xl[Pxl] 
AND(*>pl  zl:Zl[Pzl], ..,  *>Pw  zw:Zw[Pzw])  suchthat  exist  yl, yt  in 
( xc  AND(*>ocl  yl:Yl[Pylj, *>at  yt:Yt[Pyt|) 
where  min2  <  Count(yl, yt)  <  max2  )  } 
otherwise  REJECT; 

Xi 

ruleCD-06  is 

triggered  immediate_after   /*  any  ASSOCIATE  and  DISASSOCIATE  between  an  Xi  object  (this) 

i  =  l..c,  and  any  object  of  an  associated  class  involved  in  Pxi  */ 
condition  Pxi(this)  =>  ,  ....  (same  as  that  of  CD-05) 
otherwise  REJECT; 

ruleCD-07  is 

triggered  immediate_after   /*  any  ASSOCIATE  and  DISASSOCIATE  between  a  Zi  object  (this), 

i  =  l..w,  and  any  object  of  an  associated  class  involved  in  Pzi  */ 
condition  Pzi(this)  =>        (same  as  that  of  CD-05) 
otherwise  REJECT; 

Yi 

rule  CD-08  is 

triggered  immediate_after   /*  any  ASSOCIATE  and  DISASSOCIATE  between  a  Yi  object  (this), 

i  =  1  ..t,  and  any  object  of  an  associated  class  involved  in  Pyi  */ 
condition  Pyi(this)  =>        (same  as  that  of  CD-05) 
otherwise  REJECT; 

Qi 

rule  CD-09  is   /*  defined  in  a  class  Qi,  i  =  1  ..c,  which  represents  any  one  of  the  classes  involved  in 

Pxi  and  having  an  association  with  another  involved  class  represented  by  Qi'  */ 
triggered  immediate_after  /*  any  ASSOCIATE  and  DISASSOCIATE  between  a  Qi  object  and 

a  Qi'  object  */ 

condition  exist  xi  in  (xi:Xi  where  Pxi(xi,  this))  =>  (same  as  that  of  CD-05) 

otherwise  REJECT; 

Si 

rule  CD-10  is  /*  defined  in  a  class  Si,  i  =  l..w,  which  represents  any  one  of  the  classes  involved  in 

Pzi  and  having  an  association  with  another  involved  class  represented  by  Si'  */ 
triggered  immediate_after  /*  any  ASSOCIATE  and  DISASSOCIATE  between  a  Si  object  and 

a  Si'  object  */ 

condition  exist  zi  in  (zi:Zi  where  Pzi(zi,  this))  =>  (same  as  that  of  CD-05) 

otherwise  REJECT; 

Ri 

rule  CD-11  is  /*  defined  in  a  class  Ri,  i  =  l..t,  which  represents  any  one  of  the  classes  involved  in 

Pyi  and  having  an  association  with  another  involved  class  represented  by  Ri'  */ 
triggered  immediate_after  /*  any  ASSOCIATE  and  DISASSOCIATE  between  a  Ri  object  and 

a  Ri'  object  */ 

condition  exist  yi  in  (yi:Yi  where  Pyi(yi,  this))  =>  ,       (same  as  that  of  CD-05) 
otherwise  REJECT; 
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A.4  INHERITANCE  (IH) 


IH(X,  Px,  Y,  Py) 


Px 


Superclass 


Subclass 


> 

r  ® 

* 

Y 

att 


Py 


ruleIH-01  is 

triggered  before  this.att,  this.DISASSOCIATE(att,  v),  this ASSOCIATE(att,  v),  this.op 
condition  Py(this)  AND  ((not  In(att,  this.LocalAttribute))  OR  (not  In(op,  this.LocalOperation))) 

exist  x  in  ((this  *>  x:X  [Px])  where  OID(this)  =  OID(x)) 
action      x  $  this.thisOperation); 


A.5  PRIVACY  (PV) 


PV  (  X,  Px,  a,  Y,  Py,  privacy_type ) 


X 


a 


Px 


private 
or 

protected 


Y 


Py 


Y 

(superclass) 


X 

(subclass) 


Py 


Px 


rulePV-01  is 

triggered  before  this.ot,  this.ASSOCIATE(a,  y),  this.DISASSOCIATE(a,  y),  ySthis.thisOperalion) 
condition  (Px(this)  AND  Py(this.a)  AND  (privacy_type  =  "private") )  =>  (this.prior  =  this)) 
OR 

(Px(this)  AND  Py(this.a)  AND  (privacy_type  =  "protected"))  =>  ((this.prior  =  this)  OR 
((this.prior  *>  this)  AND  (OID(this.prior)  =  OID(this))))) 
otherwise  REJECT; 
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A.6  TRANSITION  (TS) 


■  TS  (  X,  Px,  a,  Y,  Py,  texp(a,  a_old) ) 


Px 


Py 


X 


a 


For  every  X  object,  if  it  satisfies  Px  and  its  old 
associated  Y  object  satisfies  Py,  then  the  old 
and  current  Y  objects  must  satisfy  the 
transition  rule  specified  in  texp. 


ruleTS-01  is 

triggered  before  this.DISASSOCIATE(a,  y) 
condition  Px(this)  AND  Py(y) 
action      this.a_old  :=  y; 

ruleTS-02  is 

triggered  before  thisASSOCIATE(a,  y) 

condition  Px(this)  AND  (this.a_old  *  nil )  =>  texp(y,  this.a_old) 
otherwise  REJECT; 
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A.7  MATHEMATICAL-DEPENDENCE  (MP) 


MD  (  X,  Px,  ((a1,  Y1,  Py1), ... ,  (at,  Yt,  Pyt )),  mexp(a1...at) ) 


Px 


> 

> 

ai 

Yi 

■  These  associations  are  constrained  by 
the  value-relationship  specified  in 
mexp(cc1...at). 


ruleMD-01  is 

triggered  immediate_after  this.ASSOCIATE(ai,  yi)    i  =  l..t 
condition  (Px(this),  Pyi(yi))  | 

exist  this  in  (this  AND(*>al  YI  [Pyi], *>ai  yi, *>at  Yt  [Pyt])) 

=>  mexp  (al...at) 
otherwise  REJECT; 
ruleMD-02  is 

triggered  immediate_after  /*  any  ASSOCIATE  and  DISASSOCIATE  between  an  X  object  (this) 

and  any  object  of  an  associated  class  involved  in  Px  */ 

condition  Px(this)  | 

exist  this  in  (this  AND(*>al  YI  [Pyi], *>at  Yt  [Pyt]))  =>  mexp  (cel.. .at) 
otherwise  REJECT; 


Yi 


ruleMD-03  is 

triggered  immediate_after   /*  any  ASSOCIATE  and  DISASSOCIATE  between  a  Yi  object  (this) 

and  any  object  of  an  associated  class  involved  in  Pyi  */ 

condition  Pyi(this)  | 

forall  x  in  (x:X  [Px]  AND(*>ocl  YI  [Pyi], *>ai  this, *>at  Yt  [Pyt])) 

suchthat  mexp  (cel.. .at) 
otherwise  REJECT; 


rule  MD-04  is  /*  defined  in  a  class  Q  which  represents  any  one  of  the  classes  involved  in  Px  and 

having  an  association  with  another  involved  class  represented  by  Q'  */ 
triggered  immediate_after  /*  any  ASSOCIATE  and  DISASSOCIATE  between  a  Q  object  and 
Q  a  Q'  object  */ 

condition  forall  x  in  (x:X  [Px]  AND(*>al  YI  [Pyi], *>at  Yt  [Pyt])) 

suchthat  mexp  (al...at) 
otherwise  REJECT; 


rule  R605  is  /*  defined  in  a  class  Ri  which  represents  any  one  of  the  classes  involved  in  Pyi  and 

having  an  association  with  another  involved  class  represented  by  Ri'  */ 
triggered  immediate_after  /*  any  ASSOCIATE  and  DISASSOCIATE  between  a  Ri  object  and 

a  Ri'  object  */ 

condition  forall  x  in  (x:X  [Px]  AND(*>al  YI  [Pyi], *>at  Yt  [Pyt])) 

suchthat  mexp  (al...at) 
otherwise  REJECT; 
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A.8  LOGICAL-DEPENDENCE  (LP) 


■  LD  (  X,  Px,  ((crt,  Y1,  Py1), ... ,  (at,  Yt,  Pyt )), 
lexp(X,  ((a1,Y1), (at,  Yt))) ) 


Px 


X 

ai 

Yi 

These  associations  are  logically 
constrained  by  the  expression 
lexp(X,  ((al.Yl),  ...,(at,Yt))) 


ruleLD-01  is 

triggered  immediate_after  ASSOCIATE(this,  (ai,  yi)),  DISASSOCIATE(this,  (ai,  yi)),  i  =  l..t 
condition  Px(this)  AND  Pyi(yi)  =>  lexp(this,  ((al,  YI), (at,  Yt))) 
otherwise  REJECT; 

ruleLD-02  is 

triggered  immediate_after  /*  any  ASSOCIATE  and  DISASSOCIATE  between  an  X  object  (this) 

and  any  object  of  an  associated  class  involved  in  Px  */ 
condition  Px(this)  AND  exist  yl, yt  in  (this  OR(*>al  yl:Yl  [Pyl], *>at  yt:Yt  [Pyt])) 

=>  lexp(this,  ((al,  Yl), ....  (at,  Yt))) 
otherwise  REJECT; 


Yi 


ruleLD-03  is 

triggered  immediate_after  /*  any  ASSOCIATE  and  DISASSOCIATE  between  a  Yi  object  (this) 

and  any  object  of  an  associated  class  involved  in  Pyi  */ 
condition  Pyi(this)  AND  exist  x  in  (this  *<ai  x:X  [Px]) 

=>  forall  x  in  (this  *<ai  x:X  [Px])  suchthat  lexp(x,  ((al,  Yl), (at,  Yt))) 
otherwise  REJECT; 


rule  LD-04  is  /*  defined  in  a  class  Q  which  represents  any  one  of  the  classes  involved  in  Px  and 

having  an  association  with  another  involved  class  represented  by  Q'  */ 
triggered  immediatc_aftcr  /*  any  ASSOCIATE  and  DISASSOCIATE  between  a  Q  object  and 

a  Q'  object  */ 
condition  exist  x  in  (x:X  [Px]) 

=>  forall  x  in  (x:X  [Px]  suchthat  lexp(x,  ((al,  Yl), (at,  Yt))) 
otherwise  REJECT; 


rule  LD-05  is  /*  defined  in  a  class  Ri  which  represents  any  one  of  the  classes  involved  in  Pyi  and 

having  an  association  with  another  involved  class  represented  by  Ri'  */ 
triggered  immediate_after  /*  any  ASSOCIATE  and  DISASSOCIATE  between  a  Ri  object  and 

a  Ri'  object  */ 
condition    exist  yi  in  (X  *>ai  yi:Yi[Pyi]) 

=>  forall  x  in  (x:X  [Px])  suchthat  lexp(x,  ((al,  Yl), (at,  Yt))) 
otherwise  REJECT; 


APPENDIX  B 

SEMANTIC  DECOMPOSITION  OF  IDEF-1X,  EXPRESS,  NIAM,  and  OSAM* 


In  the  following  four  sections,  the  semantic  decompositions  of  the  four  data 
models,  i.e.,  IDEF-1X,  EXPRESS,  NIAM,  and  OSAM*,  are  given.  The  decompositions 
of  modeling  construct  or  constraint  patterns  are  presented  with  their  corresponding 
ORECOM  representations.  Each  pattern  is  indexed  by  X-C-XX  (for  a  structural  construct) 
or  X-T-XX-X  (for  a  constraint),  where  the  first  character  can  be  I,  E,  N,  or  O  to  stand  for 
each  of  the  models  respectively,  and  the  rest  of  the  characters  are  integer  numbers  for 
numbering  the  patterns. 
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B.l  IDEF-1X 


l-C-01  (X,  (Y1,  ....  Yn) ) 


Y1 
Yn 


a  regular  entity 


MB(  X,  system-named,  (Y1,     Yn),  -,  E-CLASS,  - ,  - ) 


/*  The  three  patterns,  I-C-01, 1-C-02,  and  I-C-03,  are  used  to  capture  an  entity  defined  in  IDEF-1X,  which 
corresponds  to  an  entity-class  in  ORECOM. 
The  entity  which  satisfies  I-C-01  must  not  be  a  subtype  of  any  other  entity  and  it  also  must  not  be 
identifier-dependent  on  other  entities  (i.e.,  there  are  no  foreign-keys  as  part  of  its  primary-key).  */ 


l-C-02(X,  (Y1  Ri-1,...,Yn)) 


Zi 


Ri 


Yi 


f yV 


Yi  (FK) 
Yn 


an  entity  having 
identifier-dependency 


MB(  X,  system-named,  (Y1, ...  Ri"  , ..,  Yn), 
-,  E-CLASS,  - ,  - ) 


/*  Entity  X  is  identifier-dependent  on  entity  Zi  which  is  connected  to  X  through  Ri. 
The  dependency  is  indicated  by  the  foreign-key  Yi  of  X,  which  is  the  primary-key  of  Zi.  Graphically,  it  is 

indicated  by  the  solid  line  (instead  of  a  dash-line)  connecting  X  and  Zi  and  X  has  round  corners. 
In  ORECOM,  the  inverse  of  Ri  (instead  of  Yi  itself)  is  treated  as  an  attribute  of  X  having  Zi  as  its  domain. 


•  l-C-03  (X,  Y,  (Z1,  ...,Zm)) 


Y 


Z1 


Zm 


3" 


Z1,(FK) 
Zrri  (FK) 


a  subtype  entity 


MB(  X,  system-named,  (Z1 , Zm),  -,  Y,  -,  - ) 


/*  The  primary  key  of  X  is  directly  inherited  from  its  supertype  entity  Y,  which  implies  that  X  is  identifier- 
dependent  on  its  supertype  entity  Y.  */ 
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l-C-04  (  X,  Y,  dom(Y) ) 


an 

optional 
attribute 


f 

N 

Y(o) 

\ 

PT(  X,  -,  0,  count(X),  (Y,  dom(Y),  -)) 

PT(  dom(Y),  -,  0,  count(dom(Y)),  (Y"\  X,  -) ) 

CD((-),  (X, -),  (Y,  dom(Y), -),  1.M,  1,1  ) 


/*  I-C-04, 1-T-04-1,  and  I-T-04-2  capture  the  constraints  on  the  association  between  an  entity,  X,  and 
the  domain  of  one  of  its  non-foreign-key  attribute,  Y.  For  foreign-key  attributes,  see  from  I-C-05  to 
I-C-09.   The  'dom(Y)'  represents  the  domain  of  attribute  Y.  */ 


•  l-T-04-1  ( X,  Y,  dom(Y) ) 


r 

> 

Y 

X 

r 

> 

Y 

X 

v — ^ 


Y  (AKI) 

:  (AKi) 

l:  a 


a  non-null  attribute 


PT(  X,  -,  count(X),  count(X),  (Y,  dom(Y),  -)) 
PT(  dom(Y),  -,  0,  count(dom(Y)),  (Y1,  X,  -) ; 
CD((-),  (X, -),  (Y,dom(Y),-),1,M,1,1  ) 


/*  The  Y  in  these  three  cases,  i.e.,  a  normal  attribute  without  "(O)",  or  a  part  of  the  primary-key,  or  a  part  of 
alternate-key,  is  a  non-null  attribute  of  X.  */ 


•  l-T-04-2  (X,  ((Y1,dom(Y1), ...  (Ri"\  Zi), ...  (Yn,  dom(Yn))) ) 


a  composite  key 


Zi 


Zi 


Yi 

Yi 

Ri 


Ri 


CD((-),  (X,  -),  ((Y1 ,  dom(Y1),  -),  ....  (Ri1,  Zi,  -), 
(Y1,dom(Y1 ),-)),  1,  1,1,1  ) 


Y1 
Yi  (FK) 
Yn 


Y1(AK) 
•Yi  (FK)(AK)— 
Yn(AK) 


Y1 
Yi 
Yn 


Y1(AK) 


Yi  (AK) 
Yn(AK) 


case  1 


case  2 


case  3 


case  4 


/*  All  four  cases  show  a  composite-key  of  entity  X,  which  implies  an  one-to-one  cardinality  mapping, 
i.e.,  X  :  [(Yl,dom(Yl)),...,(Ri-1,Zi),...,(Yn,dom(Yn))]  =  [1,1]  :  [1,1]  for  case  1  and  2, 
andX  :  [(YI,  dom(Yl)), (Yi,  dom(Yi)), ....  (Yn,  domfYn))]  =  [1,1]  :  [1,1]  for  case  3  and  4.  */ 
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/*  The  following  patterns,  from  I-C-05  to  I-T-09-1,  capture  the  semantics  of  an  association  between 
two  entities.  */ 


•  l-C-05  (X,R-\Y) 

X 

Y 

PT(X, -,  0,  count(X),  (R1,Y,-)) 

f  > 

t  z 

> 

PT(  Y,  -,  0,  count(Y),  (R,  X,  -) ) 

Z  (FK)(0) 
^     i  J 

CD((-),  (X,  -),  (Pr\  Y,  -),  1,  M.1,1) 

/*  Entity  X  is  noj  existence-dependent  on  entity  Y,  which  is  indicated  by  the  "(O)"  of  the  foreign-key  Z. 
Note  that,  X  may  still  be  identifier-dependent  on  some  other  entity. 

On  the  other  hand,  the  black-dot  means  that  a  Y  instance  can  be  connected  to  ZERO,  ONE,  or  MANY 
X  instances.  */ 


l-T-05-1  (  X,  R 1 ,  Y  ) 


71 


13 


Z(FK) 

b>  i  A 


Z(FK) 


r 

Z 

> 

Y 

r 

z 

PT(  X,  -,  count(X),  count(X),  (R  ,  Y,  -) ) 
PT(  Y,  -,  0,  count(Y),  (R,  X,  -) ) 
CD((-),  (X,  -),  (R"\  Y,  -),  1 ,  M.1,1  ) 


/*  The  upper  case  shows  entity  X  is  existence-dependent  but  not  identifier-dependent  on  Y. 
The  lower  case  shows  entity  X  is  both  existence  and  identifier-dependent  on  Y.  */ 


l-C-06  (  X,  R 1 ,  Y  ) 


X 

Y 

'  z 

Z  (FK)(0) 

P 

s, 

PT(X, -,  0,  count(X),  (R-\Y,-)) 

PT(  Y,  -,  count(Y),  count(Y),  (R,  X,  -) ) 

CD((-),  (X, -),  (R-\Y,-),  1,  M.1,1) 


/*  The  "P"  together  with  the  black-dot  means  that  a  Y  instance  must  be  connected  to  at  least  ONE  X  instance.  */ 


•  l-T-06-1  (  X,  R 1 ,  Y  ) 


r 


Z(FK) 


Z(FK)\ 


f 

z 

> 

\ 

Y 

r 

z 

PT(  X, -,  count(X),  count(X),  (R1,Y, -)) 
PT(  Y,  -,  count(Y),  count(Y),  (R,  X,  -) ) 
CD((-),(X,-),(R-\  Y,-),  1,  M.1,1  ) 
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l-C-07  (  X,  R 1 ,  Y  ) 


f   z  N 

Z  (FK)(0) 
V     !  J 

v>  J 

z 

PT(X,-,0,  count(X),  (HT'.Y,-)) 
PT(  Y,  -,  0,  count(Y),  (R,  X,  -) ) 
CD((-),  (X,  -),  (FT1,  Y,  -),  1,  1,1,1  ) 


/*  The  "Z"  together  with  the  black-dot  means  that  a  Y  instance  can  be  connected  to  either  ZERO  or  ONE 
X  instance  only.  */ 


l-T-07-1  (X,  R1,  Y) 


•   

f    z  > 

Z(FK) 
^     :  J 

Z 

X 

Y 

Z(FK)\ 


R 

<  z  S 

v  J 

I  

I 

PT(  X,  -,  count(X),  count(X),  (R1 ,  Y,  -) ) 
PT(  Y,  -,  0,  count(Y),  (R,  X,  -) ) 
CD((-),  (X,  -),  (R1,  Y,  -),  1 ,  1,1,1  ) 


•  l-C-08(X,  R\Y,  k) 

'  z  N 

Z  (FK)(0) 

^  J 

0-k 

PT(X, -,  0,  count(X),  (R\Y, -)) 
PT(  Y,  -,  0,  count(Y),  (R,  X,  -) ) 
CD((-),(X,-),(R1,  Y,-),1,  k,  1,1  ) 


/*  The  "0-k"  together  with  the  black-dot  means  that  a  Y  instance  can  be  connected  to  ZERO,  ONE  or  up  to 
k  X  instances,  where  k  is  an  integer  number.  */ 


•  l-T-08-1  (  X,  R1 ,  Y,  k  ) 


X 

Z  (FK)    #  R. 

^_Jo-k 

X 


z  (fkA 


0-k 


f 

z 

\ 

Y 

z 

> 

PT(  X,  -,  count(X),  count(X),  (R1 ,  Y,  -) ) 
PT(  Y,  -,  0,  count(Y),  (R,  X,  -) ) 
CD((-),(X,-),(R-1,  Y,-),1,  k,  1,1  ) 
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l-C-09  (  X,  R 1 ,  Y,  k1 ,  k2  ) 


X 

Y 

f  z 

Z  (FK)(0) 

k1-k2 

PT(X, -,  0,  count(X),  (FT.Y,  -) ) 

PT(  Y,  -,  count(Y),  count(Y),  (R,  X,  -) ) 

CD((-),(X,  -).(R'\Y,  -),k1,k2,  1,1  ) 


/*  The  "kl-k2"  together  with  the  black-dot  means  that  a  Y  instance  must  be  connected  to  at  least  kl  and 
at  most  VI X  instances,  where  kl  and  k2  are  integer  numbers.  */ 


•  l-T-09-1  (X,  R  \  Y,  k1,  k2) 


X 

Y  N 


Z(FK) 

v   !   J  k1-k2 


r 

z 

> 

Y 

z 

> 

\ 

PT(  X,  -,  count(X)  count(X),  (R1 ,  Y,  -) ) 
PT(  Y,  -,  count(Y),  count(Y),  (R,  X,  -) ) 
CD((-),(X,  -),  (R1,Y,  -),k1,k2,  1,  1  ) 


•  l-C-10  (  X,  Y,  exp(X.d) ) 


IH(  X,  -.  Y, -) 

PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 

PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -) ) 

CD((-),(X,  -),  (-,Y,-),  1,1,1,1  ) 

LD(  X,  -,  (-,  Y,  -),  forall  x  in  (x:X  *>  Y)  suchthat  exp(X.d)) 


/*  This  pattern  captures  the  semantics  of  the  supertype-subtype  association  (or  the  CATEGORY  in  IDEF-1X). 
Entity  X  is  a  supertype  of  entity  Y  and  the  attribute 'd'  is  one  attribute  of  X,  which  is  selected  to  be  the 

DISCRIMINATOR  of  the  supertype  entity. 
Whether  an  X  instance  can  be  an  instance  of  Y  is  determined  by  its  d  value  in  the  logical  expression  'exp'.  */ 
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t  l-C-11  (X,  (Y1,  ....  Yn  )) 

X 

cb 

LD(X,-,((-,Y1,-)  (-,Yn,-»,  lexpl) 

lexpl  = 

(forall  x  in  (x:X  *>  Y1)  suchthat  NOT  exist  y2  yn  in 

(x  OR(*>  y2:Y2  *>  yn:Yn))) 

AND  AND 

(forall  x  in  (x:X  *>  Yn)  suchthat  NOT  exist  y1  yn-1  in 

(x  OR(*>y1:Y1  *>  yn-1:Yn-1))) 

I  I 

Y1    Yn 

/*  The  single  bar  beneath  the  discriminator  indicates  that  not  all  X  instances  are  supertype  instances  of 
the  subtype  entities.  However,  as  a  default  constraint  defined  in  IDEF-1X,  all  subtype  instances  are 
MUTUALLY  EXCLUSIVE.  */ 


§  l-T-11-1  (X,  (Y1  Yn  ) ) 

X 

cb 

LD(  X,  -,((-,  Y1 ,  •)  (-,  Yn,-)),  lexpl) 

lexpl  = 

(forall  x  in  (x:X  *>  Y1)  suchthat  NOT  exist  y2  yn  in 

(x  OR(*>y2:Y2  *>yn:Yn))) 

AND  AND 

(forall  x  in  (x:X  *>  Yn)  suchthat  NOT  exist  y1  yn-1  in 

(x  OR(*>y1:Y1  *>yn-1:Yn-1))) 

PT(  X,  -,  count(X),  count(X),  ((-,Y1 ,-),  ..,  (-,Yn,-))) 

i  i 

Y1    Yn 

/*  The  double  bars  beneath  the  discriminator  indicate  that  every  X  instance  must  be  a  supertype  instance 
of  some  subtype  entity. 

The  MUTUALLY  EXCLUSION  constraint  among  the  subtype  entities  still  holds  here.  */ 


•  l-C-OO(X.Y) 

Y  Y  Y 

B  6  r 


XXX 


/*  This  pattern  defines  a  "pseudo"  entity  X  in  IDEF-1X.  Each  of  X's  instance  represents  an  aggregation 
(e.g.,  set,  list,  bag,  array,  etc.)  of  instances  of  the  other  entity  Y,  which  can  be  itself  a  normal  entity,  or 
an  entity  with  identifier-dependency  on  other  entities,  or  another  pseudo  entity.  The  main  purpose  of 
defining  X  is  to  capture  entities  having  complex  structure  and  are  translated  from  other  data  models.  */ 
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B.2  EXPRESS 


/*  The  X  in  the  following  patterns  from  E-C-01  to  E-T-03-3  represents  a  simple  type  or  an  aggregation  of 
simple  type.*/  


•  E-C-01  (  Y,  agg,  k1 ,  k2,  X  ) 

SET  [k1 ,  k2]  OF  X 

LIST  [k1 ,  k2]  OF  UNIQUE  X 

MB(  Y,  self-naming,  -,  agg,  X,  -,  - ) 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -)) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),(Y,  -),  (-,  X,-),  1,M,k1,k2) 

/*  The  above  two  aggregations,  no  matter  where  they  are  specified  (in  a  TYPE  or  in  an  ENTITY),  are  defined 
as  a  new  domain-class  whose  name  is  represented  by  the  variable  Y  and  whose  domain  is  X. 
The  'agg'  in  this  pattern  can  represent  either  'SET'  or  'LIST'. 

Since  the  new  class  Y  is  defined  on  X,  every  Y  instance  must  participate  in  an  association  with  some  X 

instances,  but  not  every  X  instance  is  used  in  constructing  the  Y  instances. 
The  cardinality  is  Y  :  X  =  [1,M]  :  [kl,  k2],  meaning  each  Y  instance  is  associated  with  [kl,  k2]  X 

instances  and  an  X  instance  can  be  used  many  times  in  many  Y  instances.*/ 


•  E-C-02  (  Y,  agg,  k1 ,  k2,  X  ) 

agg  [k1 ,  k2]  OF  X 

/*  agg  =  BAG,  LIST  7 

MB(  Y,  self-naming,  -,  agg,  X,  Py,  - ) 
Py:  forall  y  in  y:Y  suchthat  k1  <  count(y  *>  X)  <  k2 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -)) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),(Y, -),(-,  X,-),  1,M,1,k2) 

/*  The  LIST  without  a  UNIQUE  constraint  or  the  BAG  allows  an  instance  of  the  newly  defined  class  Y  to 
be  associated  with  the  same  X  instance  for  more  than  one  time.  Therefore,  the  lower-bound  kl  and 
the  upper-bound  k2  should  be  checked  by  counting  the  number  of  associations  of  each  Y  instance, 
i.e.,  count(y  *>  X).  This  verification  is  specified  by  Py  as  a  membership  constraint  of  Y. 
The  cardinality  is  Y  :  X  =  [1,M]  :  [l,k2].  The  minimum  number  of  X  instance  that  a  Y  instance 
can  be  associated  with  is  ONE  (not  kl),  since  it  can  be  repeatedly  used  to  form  a  Y  instance.  */ 


•  E-C-03  (  Y,  k1 ,  k2,  X  ) 

ARRAY  [k1 ,  k2]  OF 

OPTIONAL  X 

MB(Y,  self-naming,  -.ARRAY,  X,  -,  - ) 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -)) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),(Y,  -),(-,  X,-),1,M,1,|k2-k1  +1|) 

/*  The  'kl'  and  'k2'  specify  the  minimum  and  maximum  indices  of  the  array,  so  that  each  element  of  the  array 
can  be  referenced  by  these  indices.  The  values  of  kl  and  k2  can  be  zero  or  negative  integer  numbers. 

Each  instance  of  the  newly  defined  class  Y  represented  an  array  of  fixed  number  of  elements  of  X  instances, 
where  the  number  is  limited  by  the  value  of  ik2  -  kl  +  II. 

Since  there  is  no  UNIQUE  constraint,  an  X  instance  can  be  repeatedly  used  as  elements  of  the  same  Y 
instance.  */ 
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•  E-T-03-1  (  Y,  k1 ,  k2,  X  ) 

ARRAY  [k1 ,  k2]  OF  X 

MB(Y,  self-naming,  -.ARRAY,  X,  Py,  - ) 
Py:  forall  y  in  y:Y  suchthat  count(y  *>  X)  =  |k2  -  k1  +  1 1 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -)) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),(Y,  -),  (-,  X,-),  1,M,1,|k2-k1  +  1|) 

/*  Every  element  of  a  Y  instance  MUST  not  be  empty  since  there  is  no  keyword  OPTIONAL  in  this 
specification.  In  other  words,  the  total  number  of  associations  of  every  Y  instance  is  a  fixed  value 
determined  by  Ik2  -  kl  +  II.  This  is  verified  by  the  membership  constraint  Py  in  the  MB  macro.  */ 


•  E-T-03-2  (  Y,  k1 ,  k2,  X  ) 

ARRAY  [k1 ,  k2]  OF 

OPTIONAL  UNIQUE  X 

MB(Y,  self-naming,  -.ARRAY,  X,  Py,  - ) 
Py:  forall  y  in  y:Y  suchthat 

count(y  *>  X)  =  count(x  where  x:X  <*  y) 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -)) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),(Y,  -),  (-,X,-),1,M,  1,|k2-k1  +  1|) 

/*  The  UNIQUE  constraint  requires  that  the  number  of  associations  of  a  Y  instance  equal  to  the  number  of 
X  instances  which  are  associated  with  this  Y  instance,  i.e.,  count(y  *>  X)  =  count(x  where  x:X  <*  y).  */ 


•  E-T-03-3  (  Y,  k1 ,  k2,  X  ) 

ARRAY  [k1,  k2]  OF 

UNIQUE  X 

MB(Y,  self-naming,  -.ARRAY,  X,  Py,  - ) 

Py:  forall  y  in  y:Y  suchthat  count(y  *>  X)  =  |k2  -  k1  +  1 1 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -)) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),(Y,  -),(-,  X,-),  1,M,|k2-k1  +1|,|k2-k1  +1|) 

/*  The  non-OPTIONAL  and  UNIQUE  constraints  together  require  that  the  number  of  associations  of  a  Y 
instance  equal  to  the  fixed  number  determined  by  Ik2  -  kl  +  II. 
Since  all  elements  of  a  Y  instance  must  be  non-null  and  must  also  be  distinct  X  instances,  the 
cardinality  has  to  be  the  one  as  specified  in  the  above  CD  macro.  */ 


/*  The  X  in  the  following  patterns  from  E-C-04  to  E-T-06-3  represents  a  simple  type  or  an  aggregation  of 
simple  type.  */ 


•  E-C-04  (Y,  agg,k1,k2,X) 

SET  [k1 ,  k2]  OF  X 

LIST  [k1 ,  k2]  OF  UNIQUE  X 

MB(  Y,  system-named,  -,  agg,  X,  -,  - ) 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -)) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),(Y,  -),  (-,X,-),  1,M,k1,k2) 
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•  E-C-05(Y,  agg,  k1,k2,X) 

agg  [k1 ,  k2]  OF  X 

/*  agg  =  BAG,  LIST  */ 

MB(  Y,  system-named,  -,  agg,  X,  Py,  - ) 

Py:  forall  y  in  y:Y  suchthat  k1  <  count(y  *>  X)  <  k2 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -)) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),  (Y,  -),  (-,  X,-),  1,M,  1,k2) 

•  E-C-06  (  Y,  k1 ,  k2,  X  ) 

ARRAY  [k1,  k2]  OF 
OPTIONAL  X 

MB(  Y,  system-named,  -,  ARRAY,  X,  -,  - ) 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -)) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),(Y,  -),(-,X,-),1,M,1,|k2-k1  +1|) 

•  E-T-06-1  (  Y,  k1 ,  k2,  X  ) 

ARRAY  [k1,  k2]  OFX 

MB(  Y,  system-named,  -,  ARRAY,  X,  Py,  - ) 

Py:  forall  y  in  y:Y  suchthat  count(y  *>  X)  =  |k2  -  k1  +  1 1 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -)) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),(Y,  -),(-,X,-),1,M,1,|k2-k1  +  1|) 

•  E-T-06-2  (  Y,  k1 ,  k2,  X  ) 

ARRAY  [k1 ,  k2]  OF 

OPTIONAL  UNIQUE  X 

MB(  Y,  system-named,  -,  ARRAY,  X,  Py,  - ) 
Py:  forall  y  in  y:Y  suchthat 

count(y  *>  X)  =  count(x  where  x:X  <*  y) 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -)) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),(Y,  -),  (-,X,-),1,M,1,|k2-k1  +  1|) 

•  E-T-06-3  (  Y,  k1 ,  k2,  X  ) 

ARRAY  [k1,  k2]  OF 

UNIQUE  X 

MB(  Y,  system-named,  -,  ARRAY,  X,  Py,  - ) 

Py:  forall  y  in  y:Y  suchthat  count(y  *>  X)  =  |k2  -  k1  +  1 1 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -)) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),  (Y,  -),  (-,  X,-),  1 ,  M,  |k2  -  k1  +  1 1,  |k2  -  k1  +  1 1  ) 

•  E-C-07  (  Y,  X,  width  ) 

...  [agg]  ...  X  (width)  ; 
/*  X  is  a  simple  type  */ 

MB(  Y,  self-naming,  -,  -,  X,  width  ,  - ) 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  width) ) 
PT(X,  width,  count(X),  count(X),  (-,  Y, -) ) 
CD((-),(Y,  -),(-,  X,  width),  1,  1,  1,  1  ) 

/*  A  simple  type  plus  a  width-specification,  no  matter  where  it  is  specified  (in  a  TYPE  or  an  ENTITY), 
is  defined  to  be  a  new  domain-class  Y  in  ORECOM  and  the  width-specification  is  used  as  the 
membership  constraint  of  the  MB  macro.  */ 
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•  E-C-08  (  X,  dom(X),  P  ) 

TYPE 

X=  [agg]  Y  [width]; 
[where  p;] 

/*  Y  is  a  simple  type.  */ 

MB(  X,  self-naming,  -,  -,  dom(X),  P,  - ) 
PT(  X,  -,  count(X),  count(X),  (-,  dom(X),  P) ) 
PT(dom(X),  P,  count(dom(X)),  count(dom(X)),  (-,  X,  -) ) 
CD((-),(X,  -),(-,  dom(X),  P),  1,1,1,1  ) 

/*  X  is  a  defined-type  in  EXPRESS  and  is  defined  to  be  a  domain-class  in  ORECOM,  whose  domain  can  be 
a  simple  or  an  aggregated  simple  type,  and  can  have  a  width-specification  with  it.  If  the  domain  is  not 
a  simple  type,  then  it  must  be  defined  as  another  domain-class  and  represented  by  one  of  the  previous 
patterns.  We  use  "dom(X)"  to  stand  for  this  domain-class.  */ 


•  E-C-09  (  X,  dom(X),  P  ) 

TYPE 

X  =  [agg]  Y; 

[WHERE  P;] 
/*  Y  is  an  entity  type.  */ 

MB(  X,  system-named  -,  -,  dom(X),  P,  - ) 
PT(  X,  -,  count(X),  count(X),  (-,  dom(X),  P) ) 
PT(dom(X),  P,  count(dom(X)),  count(dom(X)),  (-,  X,  -) ) 
CD((-),(X,  -),(-,  dom(X),  P),  1,1,1,1  ) 

•  E-C-10(X,  (y1  yn)) 

TYPE 

X=  ENUMERATION  OF 

(yi  yn); 

MB(X,  self-naming,  -,  -,  STRING,  {y1  yn} ,  - ) 

PT(  X,  -,  count(X),  count(X),  (-,  STRING,  {y1  yn}) ) 

PT(STRING,  {y1  yn},  count(STRING), 

count(STRING),  (-,  X,  -) ) 
CD((-),(X,  -),(-,  STRING,  {y1  yn}),  1,1,1,1  ) 

/*  X  is  an  enumeration  type  whose  value  can  only  be  character  strings  specified  by  (yl, yn). 
In  the  MB  macro,  we  use  the  set  notation  {yl, yn}  to  represent  the  domain  values  of  X  and  treat  it  as 
a  membership  constraint  of  X.  */ 

•  E-C-11  (X,  (Y1  Yn)) 

TYPE 

X=  SELECT  (Y1,  ....  Yn); 
/*  Y1  Yn  are  simple  types.  */ 

MB(X,  self-naming,  -,  -,  (Y1  U  Y2  U  ...  U  Yn),  -,  - ) 
PT(X, -,  0,  count(X),  (-,  Yi -) ),  i  =  1..n 

PT(  X,  -,  count(X),  count(X),  ((-,  Y1 ,  -)  (-,  Yn,  -)) ) 

PT(  Yi,  -,  count(Yi),  count(Yi),  (-,  X, -) ),  i»1..n 
CD((-),  (X,  -),(-,  Yi,  -),  1,  1, 1,  1  ),  i  =  1..n 

/*  X  is  a  select-type  whose  value  can  be  any  one  of  the  specified  set  of  simple  types  (Yl, Yn). 
In  ORECOM,  X  is  then  defined  to  be  a  domain-class  and  its  class  type  is  the  union  of  Yl  ..  Yn.  */ 

•  E-C-12(X,  (Y1  Yn)) 

TYPE 

X=  SELECT  (Y1 ,  Yn); 
r  Y1, Yn  are  entity  types.  7 

MB(X,  system-named,  -,  -,  (Y1  U  Y2  U  ...  U  Yn),  -,  - ) 
PT(X, -,  0,  count(X),  (-,  Yi -) ),  i  =  1..n 
PT(  X,  -,  count(X),  count(X),  ((-,  Y1 ,  -), (-,  Yn,  -)) ) 
PT(  Yi,  -,  count(Yi),  count(Yi),  (-,  X, -) ),  i  =  1..n 
CD((-),(X,-),(-,Yi,-),  1,1,1,1  ),  i=1..n 

115 


•  E-C-13(X) 

ENTITY  X  [supertype  of  ....]; 

MB(  X,  system-named,  -,  -,  E-CLASS,  -,  - ) 

/*  X  must  not  be  a  subtype  entity  of  any  other  entity.  */ 

•  E-C-14(X,  Y,  -) 

ENTITY  X  SUBTYPE  OF  (Y); 

MB(  X,  system-named,  -,  -,  Y,  -,  - ) 

/*  X  is  a  subtype  of  entity  Y  and  Y  is  the  only  supertype  entity  of  X.  */ 

•  E-T-14-1  (  X,  (Y1  Yn) ) 

ENTITY  X  SUBTYPE  OF  (Y1,..,Yn); 

MB(  X,  system-named,  -,  -,  (Y1 , ..,  Yn),  -,  - ) 

/*  X  is  a  subtype  of  more  than  one  entity  and,  therefore,  its  class  type  in  ORECOM  is  any  one  of  these 

supertype  entities,  Yl...Yn.  */ 

•  E-C-15(X,  Y,  dom(Y) ) 

ENTITY  X  [SUPER/SUBTYPE  OF  ...]; 

PT(  X,  -,  0,  count(X),  (Y,  dom(Y),  -) ) 

[DERIVE  |  INVERSE] 

PT(  dom(Y),  -,  0,  count(dom(Y)),  (Y"\  X,  -) ) 

Y:  OPTIONAL  [agg]  W  [width]; 

CD((-),(X,  -),(Y,  dom(Y),-),  1.M,  1,1  ) 

/*  This  basic  pattern  captures  the  constraints  between  an  entity  X  and  the  domain  of  its  optional  attribute  Y. 
The  Y  can  also  be  a  derived  or  inverse  attribute  at  the  same  time  but  the  associated  constraints  will  be 

captured  by  other  patterns  shown  below. 
The  'dom(Y)'  represents  the  domain  of  the  attribute  Y,  which  can  be  a  simple  type  or  an  aggregation  of 
some  simple  type,  plus  an  optional  width-specification.  */ 


•  E-T-15-1  (X,  Y,  dom(Y)) 

[DERIVE  |  INVERSE]  Y:  [agg]  W  [width]; 
/*  No  "OPTIONAL".  */ 

PT(  X,  -,  count(X),  count(X),  (Y,  dom(Y),  -) ) 
PT(  dom(Y),  -,  0,  count(dom(Y)),  (Y1,  X,  -) ) 
CD((-),  (X,  -),  (Y,  dom(Y), -),  1.M.1.1  ) 

/*  Same  as  the  above  pattern  except  that  Y  is  a  non-null  attribute  of  X.  */ 

•  E-C-16  (X,  Y,  dom(Y) ) 

ENTITY  X  [SUPER/SUBTYPE  of  ...]; 

[DERIVE  |  INVERSE] 

Y:  OPTIONAL  [agg]  W  [width]; 

PT(  X,  -,  0,  count(X),  (Y,  dom(Y),  -) ) 

PT(  dom(Y),  -,  0,  count(dom(Y)),  (Y'\  X,  -) ) 

CD((-),(X,  -),  (Y,  dom(Y),-),  1,M,  1,1  ) 

/*  Same  as  the  pattern  E-C-15  except  that  the  domain  of  Y  is  an  entity  type  or  an  aggregation  of  entity  type. 

•  E-T-16  -1  (  X,  Y,  dom(Y) ) 

[DERIVE  |  INVERSE]  Y:  [agg]  W  [width]; 
/*  No  "OPTIONAL".  7 

PT(  X,  -,  count(X),  count(X),  (Y,  dom(Y),  -) ) 
PT(  dom(Y),  -,  0,  count(dom(Y)),  (Y'\  X,  -) ) 
CD((-),(X,  -),  (Y,  dom(Y),-),1,M,1,1  ) 
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•  E-T-1 51 6-2  (  X,  ((Y1 ,  dom(Y1 )), (Yn,  dom(Yn)) ) 

UNIQUE  Y1  Yn; 

CD((-)(  (X,  -),  ((Y1,  (dom(Y1),  -), ..,  (Yn,  dom(Yn),  -)), 
1.1.1,1  ) 

/*  The  UNIQUE  constraint  requires  that  X:  [(Yl,  dom(Yl)), ....  (Yn,  dom(Yn))]  =  [1,1]  :  [1,1]. 
The  domains  of  Yl...Yn  can  be  simple  types,  aggregations  of  simple  types  (plus  width-specification),  or 
entity  types  or  aggregations  of  entity  types.  */ 


•  E-T-1 51 6-3  (  X,  ((Y,dom(Y)) 

,  (Z1  ,dom(Z1)),      (Zn,dom(Zn))), expression  (Y,Z1..Zn)  ) 

DERIVE  Y: 

[OPTIONAL]  [agg]  W  [width] 
:=  expression  (Z1..Zn); 

MD(X,  -,  ((Y,  dom(Y),  -),  (Z1 ,  dom(Z1),  -),  ...  (Zn,  dom(Zn),  -)), 
expression  (Y,  Z1 , ....  Zn) ) 

/*  Y  is  a  derived  attribute  whose  domain  is  represented  by  dom(Y)  and  whose  value  is  derived  by  the  given 
expression  invloving  attributes  Zl...Zn.  */ 


•  E-T-1516-4(X,  Y,  Y  \  dom(Y),  W  ) 

INVERSE  Y:  [agg]  W  FOR  Y1; 

LD(X,  -,  (Y,  dom(Y)  -),  forall  x  in  x:X  suchthat 

exist  x'  in  x':X  where,  x1  =  x.Y.W.Y'1  .X) ) 

/*  Y  is  an  attribute  of  X  and  also  an  inverse  of  the  attribute  Y1  of  entity  W.  */ 
-v  aKK 


-1 

w 

•  E-T-1 51 6-5  (  X,  ((Y1 ,  dom(Y1 ))  (Yn,  tiomiYnW^xpressioniY-l  Yn) ) 

WHERE  expression{Y^  Yn); 

LD(X,  -,  ((Y1,  dom(Y1),  -),  ..,  (Yn,  dom(Yn),  -)), 
expression  (Y1, Yn) ) 

/*  The  given  expression  in  the  WHERE-clause  specifies  a  constraint  on  the  attributes  Yl  ...Yn  of  X.  */ 


•  E-C-17(X,  Y,  -) 

IH(X, -,  Y, -) 

ENTITY  Y 

PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 

SUBTYPE  OF  (  ...  X,  ...); 

PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -) ) 

CD((-),(X,  -),  (-,Y,-),  1,1,1,1  ) 

/*  This  pattern  captures  the  constraints  between  a  supertype  entity,  X,  and  one  of  its  subtype  entities,  Y.  */ 
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•  E-C-18(X,  (Y1  Yn) ) 

ENTITY  X  SUPERTYPEOF 

(Y1  ANDOR  Y2  ANDOR  ....  ANDOR  Yn); 

LD(X,  -,  ((-,  Y1,-)  (-,  Yn,  -)),  lexpl) 

lexpl  =  forall  x  in  (x:X)  suchthat  exist  y1  yn  in 

(x  OR(*>y1:Y1  *>  yn:Yn)) 

•  E-T-18-1  (X,  (Y1  Yn)) 

ENTITY  X  SUPERTYPEOF 

(ONEOF  (Y1  ,  Y2,  .....  Yn); 

LD(X,  -,  ((-,  Y1,-)  (-,  Yn,  -)).  Iexp2) 

Iexp2  = 

(forall  x  in  (x:X  *>  Y1 )  suchthat  NOT  EXIST  y2, 

....  yn  in  (x  OR(*>  y2:Y2  yn:Yn))) 

AND  AND 

(forall  x  in  (x:X  *>  Yn)  suchthat  NOT  EXIST  y1 , 
....  yn-1  in  (x  OR(*>  y1  :Y1  yn-1  :Yn-1 ))) 

•  E-C-19(X,  (Y1 1  Ykrik)) 

ENTITY  X  SUPERTYPEOF 
((Y11...Y1m)  ANDOR  (Y21...Y2n2)  ANDOR 
....  ANDOR  (Yk1...Yknk)); 

LD(X,  -,  ((-,  Y11,  -)  (-,  Yknk,  -)),  Iexp3) 

Iexp3  = 

(forall  x  in  (x:X)  suchthat  exist  y1 1  y1  m  in 

(xOR(*>y11:Y11  *>  y1m:Y1ni))  OR  ....  OR 

(forall  x  in  (x:X)  suchthat  exist  yk1  yknk  in 

(x  OR(*>  yk1  :Yk1  *>  yknk:Yknk)) 

/*  Same  as  the  pattern  of  E-C-18  except  that  the  operands  of  these  ANDORs  are  expressions,  some  of  which 
are  complex  expressions  of  more  than  one  subtype  entity  using  other  ANDOR  or  ONEOF  operators.  */ 


•  E-T-19-1  (  X,  (Y11,     Yknk)  ) 

ENTITY  X  SUPERTYPEOF 

(....  ONEOF((Y1 1  ...Y1  m),     ,  (Yk1  ...Yknk))  ...); 

LD(X,  -,  ((-,  Y11,  -)  (-,  Yknk,  -)),  Iexp4) 

Iexp4  = 

(forall  x  in  (x:X  OR(*>  Y1 1 , ...  *>  Y1  m))  suchthat 

NOT  exist  y21  ..yknk  in  (x  AND(!>  y21  :Y21  

!>  yknk:  Yknk))) 

AND  AND 

(forall  x  in  (x:X  OR(*>  Yk1  *>  Yknk))  suchthat 

NOT  exist  y1 1  ..y(k-1  )n<k-i)  in 

(x  AND(!>  y1 1  :Y1 1  !>  y(k-1  )n<k-n:Y(k-1)n<k-i)))) 

/*  Same  as  the  pattern  of  E-T-18-1  except  that  the  operands  of  these  ANDORs  are  expressions,  some  of 
which  are  complex  expressions  of  more  than  one  subtype  entity  using  other  ANDOR  or  ONEOF  operators. 

*/ 


•  E-T-1819-2  (  X,  (Y1  Yn)  ) 

ENTITY  X 

ABSTRACT  SUPERTYPE  OF  (Y1  Yn); 

PT(  X,  -,  count(X),  count(X),  ((-,Y1,-)  (-.Yn,-))) 

/*  The  keyword  'ABSTRACT'  requires  all  X  instances  to  be  also  instances  of  some  of  its  subtype  entities.  */ 


/*  Note  that,  the  'AND'  operator  is  not  specified  here  to  be  a  pattern  because  it  only  indicates  that  there  are 
more  than  one  group  of  subtype  entities  of  X.  It  does  not  bring  any  constraint  on  the  subtype  entities.  */ 
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B.3NIAM 


•  N-C-01  (  Y,  Z,  P) 

(  X  )     domw  = z  ipi 

MB(  Y,  self-naming,  -,  -,  Z,  P,  - ) 
PT(  Y,  -,  count(Y),  count(Y),  (-,  Z,  P) ) 
PT(  Z,  P,  count(Z),  count(Z),  (-,  Y,  -) ) 
CD(  (-),  (Y,  -),(-,  Z,  P),  1,  1,1,1  ) 

/*  Z  is  the  domain  of  the  LOT  (Lexical  Object  Type)  X,  which  is  defined  to  be  a  domain-class  Y  in 
ORECOM.  The  'F  represents  any  additional  constraint  of  the  domain  of  X,  e.g.,  width-specification, 
which  is  treated  as  a  membership  constraint  of  Y  in  the  MB  macro.  */ 


•  N-C-02  (  Xset,  SET,  1 ,  M,  dom(X) ) 

<  >— 

0  \ 

— :  x  :■ 

%  / 

MB(  Xset,  self-naming,  -,  SET,  dom(X),  -,  - ) 
PT(  Xset,  -,  count(Xset),  count(Xset),  (-,  dom(X),  -) ) 
PT(  dom(X),  -,  0,  count(dom(X)),  (-,  Xset,  -) ) 
CD((-),  (Xset,  -),  (-,  dom(X),  -),  1 ,  M,  1 ,  M  ) 

/*  The  NOLOT  (Non-Lexical  Object  Type)  has  a  multi-valued  attribute  X  whose  original  domain  is 
denoted  by  dom(X). 

The  domain  of  this  multi-valued  attribute  is  then  defined  to  be  a  new  domain-class  called  'Xset'. 

The  same  instance  of  dom(X)  can  be  used  as  values  of  the  attribute  X  of  different  NOLOT  instance.  */ 


•  N-T-02-1  (  Xset,  SET,  1 ,  M,  c 

om(X) ) 

O  Kx) 

MB(  Xset,  self-naming,  -,  SET,  dom(X),  -,  - ) 
PT(  Xset,  -,  count(Xset),  count(Xset),  (-,  dom(X),  -)) 
PT(  dom(X),  -,  0,  count(dom(X)),  (-,  Xset,  -) ) 
CD((-),  (Xset,  -),  (-,  dom(X),  -),  1, 1,  1,  M  ) 

(*  Same  as  the  above  pattern  except  that  the  same  instance  of  dom(X)  can  NOT  be  used  as  values  of  the 
multi-valued  attribute  X  of  different  NOLOT  instance.  */ 

•  N-C-03  (  X  ) 

f  \/)     f  X  must  not  be 
J        a  sub-type.  */ 

MB(  X,  system-named,  -,  -,  E-CLASS,  -,  - ) 

/*  X  is  a  NONLOT  in  NIAM  and  is  defined  to  be  an  entity-class  in  ORECOM  whose  class  type  is 
the  system-defined  class  E-CLASS  since  it  is  not  a  subtype  of  any  other  NOLOTs.  */ 

•  N-C-04  (  X,  Y,  - ) 

MB(  X,  system-named,  -,  -,  Y,  -,  - ) 

/*  X  is  a  subtype  of  Y  and  only  Y.  */ 
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•  N-T-04-1  (X,  (Y1,  .. 

-Yn)) 

® 

-* 

MB(  X,  sysiem-named,  -,  -,  (Y1  Yn),  -,  - ) 

/*  X  is  a  subtype  of  more  than  one  NOLOTs.  */ 


•  N-C-05  (  Xset,  SET,  1,  M,  X  ) 

<  H 

MB(  Y,  system-named,  -,  SET,  dom(X),  -,  - ) 
PT(  Y,  -,  count(Y),  count(Y),  (-,  dom(X),  -)  ) 
PT(  dom(X),  -,  0,  count(dom(X)),  (-,  Y,  -) ) 
CD((-),(Y,  -),  (-,  dom(X), -),  1,M,1,M) 

/*  Same  as  N-C-02  except  that  X  is  a  NOLOT.  */ 


•  N-C-06  (  X,  Y,  dom(Y) ) 

<«>- 

— :  y  j 

PT(  X,  -,  0,  count(X),  (Y,  dom(Y),  -) ) 
PT(dom(Y),  -,  0,  count(dom(Y)),  (Y1,  X,  -) ) 
CD((-),  (X, -),  (Y,  dom(Y), -)),  1.M.1.1  ) 

/*  The  main  purpose  of  this  pattern  is  to  capture  the  constraints  contained  on  the  association  between  X  and 
the  domain  of  the  single-valued  attribute  Y,  which  is  represented  by  dom(Y).  */ 


•  N-T-06-1  (  X,  Y,  dom(Y) ) 

PT(  X,  -,  count(X),  count(X),  (Y,  dom(Y),  -) ) 
PT(dom(Y),  -,  0,  count(dom(Y)),  (Y\X,  -) ) 
CD((-),  (X,  -),  (Y,  dom(Y),  -)),  1.M.1.1  ) 

(*> 

/*  Same  as  the  above  pattern  except  that  Y  becomes  a  non-null  attribute  of  X.  */ 


•  N-T-06-2  (  X,  Y,  dom(Y) ) 

PT(  X,  -,  0,  count(X),  (Y,  dom(Y),  -) ) 
PT(dom(Y),  -,  0,  count(dom(Y)),  (Y1,  X,  -) ) 
CD((-),  (X,  -),  (Y,  dom(Y),  -)),  1,1,1,1  ) 

0-  '<D 

/*  The  right  short  bar  specifies  a  uniqueness  constraint  on  Y.  */ 


•  N-T-06-3  (  X,  Y,  dom(Y) ) 

*  * 

— f  Y  ' 

PT(  X,  -,  count(X),  count(X),  (Y,  dom(Y),  -) ) 
PT(dom(Y),  -,  0,  count(dom(Y)),  (Y1,  X,  -) ) 
CD((-),  (X,  -),  (Y,  dom(Y),  -)),  1,1,1,1  ) 

120 


•  N-T-06-4  (  X,  Y,  Yset ) 

CH 

/  % 

PT(  X,  -,  0,  count(X),  (Y,  Yset,  -) ) 
PT(Yset,  -,  0,  count(Yset),  (Y"\  X,  -) ) 
CD((-),  (X, -),  (Y,  Yset, -),  1,M,  1,1  ) 

/*  The  main  purpose  of  this  and  the  next  patterns  is  to  capture  the  constraints  on  the  association  between 
X  and  the  domain  of  the  multi- valued  attribute  Y,  which  is  represented  by  Yset.  */ 


•  N-T-06-5  (  X,  Y,  Yset ) 

PT(  X,  -,  count(X),  count(X),  (Y,  Yset,  -) ) 
PT(Yset, -,  0,  count(Yset),  (Y-1.X,-)) 
CD((-),  (X,  -).  (Y,  Yset,  -),  1,M,  1,1  ) 

•  N-T-06-6  (  X,  Y,  Yset ) 

PT(  X,  -,  0,  count(X),  (Y,  Yset,  -) ) 
PT(Yset, -,  0,  count(Yset),  (Y  \X, -)) 
CD((-),  (X, -),  (Y,  Yset, -),  1,1,1,1  ) 

©- 

/*  Y  is  a  multi-valued  attribute  of  X  and  each  instance  of  the  domain  of  this  attribute  (i.e.,  Yset)  can  only 
be  associated  with  one  X  instance.  */ 


•  N-T-06-7  (  X,  Y,  Yset ) 

PT(  X,  -,  count(X),  count(X),  (Y,  Yset,  -) ) 
PT(Yset,-,  0,  count(Yset),  (Y  \X, -)) 
CD((-),  (X, -),  (Y,  Yset, -),  1,1,1,1  ) 

(*>  -w 

/*  Same  as  above  except  that  Y  becomes  a  non-null  multi-valued  attribute  of  X.  */ 


•  N-C-07  (X,  a,  Y  ) 

PT(  X,  -,  0,  count(X),  (a,  Y,  -) ) 
PT(Y,-,  0,  count(Y),  (a\X,-)) 
CD((-),  (X,  -),  (a,  Y,  -),  1,M,  1,1  ) 

©-  a  a'-0 

/*  Starting  from  N-C-07  to  N-T-07-5  are  patterns  showing  the  constraints  on  the  association  between  two 
NOLOTs,  X  and  Y,  where  we  assume  Y  is  the  domain  of  the  single-valued  attribute  'a'  of  X.  */ 


•  N-T-07-1  (X,  a,  Y  ) 

PT(  X,  -,  count(X),  count(X),  (a,  Y,  -) ) 
PT(Y, -,  0,  count(Y),  (a\X,  -) ) 
CD((-),  (X,  -),  (a,  Y,  -),  1,M,  1,1  ) 

0^  a    a  '  -Q 

•  N-T-07-2  (X,  a,  Y  ) 

PT(  X,  -,  0,  count(X),  (a,  Y,  -) ) 

PT(Y,  -,  count(Y),  count(Y),  (a  \X, -)) 

CD((-),  (X,  -),  (a,  Y,  -),  1,M,1,1  ) 

0—  a  y(y) 
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•  N-T-07-3  (X,  a,  Y  ) 

PT(  X,  -,  0,  count(X),  (a,  Y,  -) ) 
PT(Y,-,  0,  count(Y),  (a\X,-)) 
CD((-),  (X,  -),  (a,  Y,  -),  1,1,1,1  ) 

(7y  a  a-.-0 

•  N-T-07-4  (X,  a,  Y  ) 

PT(  X,  -,  count(X),  count(X),  (a,  Y,  -) ) 
PT(Y,-,  0,  count(Y),  (a  \  X, -) ) 
CD((-),  (X,  -),  (a,  Y,  -),  1,1,1,  1  ) 

(x)v-  a    a  <  -Q 

•  N-T-07-5  (X,  a,  Y  ) 

PT(  X,  -,  0,  count(X),  (a,  Y,  -) ) 

PT(Y, -,  count(Y),  count(Y),  (a1,  X,  -) ) 

CD((-),  (X,  -),  (a,  Y,  -),  1,1,1,1  ) 

Q—  a    a-'  V© 

•  N-T-07-6  (  X,  a,  Yset ) 

PT(  X,  -,  0,  count(X),  (a,  Yset,  -) ) 
PT(Yset, -,  0,  count(Yset),  (a  \X,  -) ) 
CD((-),  (X, -),  (a,  Yset, -),  1,M,  1,1  ) 

0-  a  a'-0 

/*  This  and  the  next  two  patterns  assume  that  'a'  is  the  multi-valued  attribute  of  X,  whose  values  are 
instances  of  the  class  Yset  which  is  defined  using  N-C-05.  */ 


•  N-T-07-7  ( X,  a,  Yset ) 

PT(  X,  -,  count(X),  count(X),  (a,  Yset,  -) ) 
PT(Yset,  -,  0,  count(Yset),  (a1,  X,  -) ) 
CD((-),  (X, -),  (a,  Yset, -),  1,M,  1,1) 

•  N-T-07-8  (  X,  a,  Yset ) 

PT(  X,  -,  0,  count(X),  (a,  Yset,  -) ) 

PT(Yset, -,  count(Yset),  count(Yset),  (a1,  X,  -) ) 

CD((-),  (X, -),  (a,  Yset, -),  1,M,  1,1  ) 

Q—  a    a-  y(y) 
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•  N-C-08  (  X,  {Y},  {Z}  ) 

(X)       f  or 

LD(  X,  -,  (({Y},  -),  ({Z},  -)),  expl  ) 
expl  = 

(forall  x  in  (x:X  *>  {Y})  suchthat  exist  z  in  (x  *>  z:{Z})) 
AND 

(forall  x  in  (x:X  *>  {Z})  suchthat  exist  y  in  (x  *>  y:{Y})) 

/*  The  'E'  represents  a  set-equivalence  constraint  added  between  two  attributes  of  X. 

Since  the  Y  and  Z  can  be  both  LOTs  or  NOLOTs  or  a  LOT  and  a  NOLOT,  we  use  { Y}  and  [Z]  to 

represent  the  pairs  of  an  attribute  name  and  its  domain. 
For  example,  if  Y  is  a  LOT  and  a  single-valued  attribute  of  X,  then  {Y}  will  be  equal  to  (Y,  dom(Y)). 
As  another  example,  if  Y  is  a  LOT  and  a  multi-valued  attribute  of  X,  then  { Y}  is  equal  to  (Y,  Yset).  */ 


•  N-C-09(X,  dom(X),Y,Z) 

■:  x  :■  § 

"-\-^  -0 

LD(  dom(X),  -,  ((X1,  Y,  -),  (X1,  Z,  -)),  exp2) 
exp2  = 

(forall  d  in  (d:dom(X)  *<X  Y)  suchthat  exist  z  in  (d  *<X  z:Z)) 
AND 

(forall  d  in  (dom(X)  *<X  Z)  suchthat  exist  y  in  (d  *<X  y:Y)) 

/*  The  LOT  X  serves  as  a  common  attribute  to  Y  and  Z,  and  the  E-constraint  requires  that  if  an  X  instance 
is  used  as  an  attribute  value  of  Y  then  it  must  also  be  used  for  Z,  and  vice  versa.  */ 


•  N-C-10(X,  {Y},{Z}) 

LD(  X,  -,  (({Y},  -),  ({Z},  -)),  exP3  ) 
exp3  = 

(forall  x  in  (x:X  *>  {Y})  suchthat  NOT  exist  z  in  (x  *>  z:(Z})) 
AND 

(forall  x  in  (x:X  *>  {Z})  suchthat  NOT  exist  y  in  (x  *>  y:{Y})] 

Y  ^LOT 

(x) 

'         j_        V  NOLOT 

/*  The  'X'  specifies  a  mutually  exclusive  constraint  between  the  two  attributes  of  X.  */ 


•  N-C-11  (  X,  dom(X),  Y,  Z  ) 

.-/-^  -0 

fx  J  H 

""^  -<z) 

LD(  dom(X),  -,  ((X\  Y,  -),  (X1,  Z,  -)),  exp4) 
exp4  = 

(forall  d  in  (d:dom(X)  *<X  Y)  suchthat  NOT  exist  z  in  (d  *<X  z:Z)) 
AND 

(forall  d  in  (d:dom(X)  *<X  Z)  suchthat  NOT  exist  y  in  (d  *<X  y:Y)) 
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•  N-C-12(X,  {Y},{Z}) 

S  or 

—  z  * 

LD(  X,  -,  (({Y},  -),  ({Z},  -)),  exP5  ) 

exp5  =  forall  x  in  (x:X  *>  {Y}) 

suchthat  exist  z  in  (x  *>  z:{Z}) 

/*  The 'S'  specifies  a  set-subset  constraint  such  that  if  an  X  instance  has  an  attribute  value  from  the  Y  side 
then  it  must  also  has  an  attribute  value  from  the  Z  side.  */ 


•  N-C-13(X,  dom(X),  Y,  Z  ) 

( x  :■ 

LD(  dom(X),  -,  ((X1,  Y,  -),  (X1,  Z,  -)),  exp6) 

exp6  =  forall  d  in  (d:dom(X)  *<X  Y) 
suchthat  exist  z  in  (d  *<X  z:Z) 

•  N-C-14(X,  ({Y1},... 

,  {Yn}) ) 

Y1 

\ 

LOT 
or 

CD((-),(X,-),(({Y1},-),...,({Yn},-)),  1,  1,  1,  1  ) 

^-NOLOT 

Yn 

/*  The  'U'  specifies  a  uniqueness  constraint  such  that  each  instance  combination  of  Yl...Yn  can  uniquely 
determine  an  X  instance.  */ 

•  N-T-14-1  (X,  ({Y1}, 

....  {Yn}) ) 

Y1 

(x)  Qj) 

\ 

LOT 

or 

CD((-),(X,-),(({Y1}, -),... ,({Yn},-)),  1,  1,  1,  1  ) 

w 

s NOLOT 

Yn 

/*  Same  as  the  above  pattern  except  each  attribute  is  a  non-null  attribute.  */ 
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•  N-C-15(X,  Y) 

IH(  X,  -,  Y,  - ) 

©— © 

PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 

PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -) ) 

CD((-),(X,  -),  (-,Y,-),  1,1,1,1  ) 

/*  Y  is  a  subtype  of  X.  */ 


•  N-C-16(X,  (Y1  Yn)) 

LD(  X,  -,((-,  Y1,-)  (-,  Yn,  -)), 

forall  x  in  x:X  suchthat  exist  y1 , yn  in 

(xOR(*>  y1:Y1  *>  yn:Yn)) ) 

(Y1...Yn  represent  all  subtypes  of  X.) 

/*  If  X  has  more  than  one  subtype  NOLOTs,  Yl...Yn,  then,  as  a  default  condition,  these  subtype  NOLOTs 
are  not  mutually  exclusive,  i.e.,  an  X  instance  can  be  instances  of  more  than  one  subtypes.  */ 


•  N-T-16-1  (X,  (Y1,...,Yn)) 

(y^^) 

PT(  X,  -,  count(X),  count(X),  ((-,  Y1 ,  -),  ....  (-,  Yn,  -)) ) 

/*  Same  as  above  except  the  total-specialization  constraint.  */ 


•  N-T-16-2  (X,  (Y1,  ....  Yn)  ) 

LD(X,  -,  ((-,Y1,-)  (-,  Yn,  -)),  exp7  ) 

exp7  =  (forall  x  in  (x:X  *>  Y1 )  suchthat  NOT  exist  y2  Yn  in 

(x  OR(*>  y2:Y2  *>  yn:Yn)) ) 

AND  AND 

(forall  x  in  (x:X  *>  Yn)  suchthat  NOT  exist  y1  Yn-1  in 

(x  OR(*>y1:Y1  *>  yn-1:Yn-1)) ) 

/*  The  subtype  NOLOTs  arc  mutually  exclusive,  i.e.,  an  X  instance  can  be  an  instance  of  only  one  subtype 
ofYl...Yn.  */ 
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B.4QSAM* 


•  O-C-01  (  X,  Y,  Py  ) 

a  D-class 

dom(X)  =  Y  [Py] 

MB(  X,  self-naming,  -,  -,  Y,  Py,  - ) 
PT(  X,  -,  count(X),  count(X),  (-,  Y,  -) ) 
PT(Y,  Py,  count(Y),  count(Y),  (-,  X, -) ) 
CD((-),  (X,  -),(-,  Y,  Py),  1,1,1,1  ) 

/*  X  is  a  domain-class  defined  in  OSAM*  whose  domain  is  Y  and  may  have  a  domain  constraint  such  as 
width-specification. 
The  domain  Y  itself  can  be  a  simple  or  complex  data  type.  */ 


•  O-C-02  (  Y,  SET,  k1,  k2,  X) 

z  (F) 

MB(Y,  self-naming,  -,  SET,  X,-,-) 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -) ) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),  (Y,  -),(-,  X, -),  1,M,k1,  k2) 

att  att| 

SET[k1 ,  k2]     JSET[k1 ,  k2] 

0  0 

/*  Y  is  a  newly  defined  domain-class,  each  of  its  instances  represents  a  set  of  kl  to  k2  X  instances. 
The  new  class  Y  is  then  used  as  the  domain  of  attribute  'att'  of  Z. 

The  cardinality  between  the  new  class  Y  and  its  domain  X  is  Y  :  X  =  [1,  M] :  [kl,  k2].  */ 


•  O-C-03  (  Y,  agg,  k1,  k2,  X) 

 T   © 

MB(  Y,  self-naming,  -,  agg,  X,  Py,  - ) 

Py  =  forall  y:Y  suchthat  k1  <  count(y  *>  X)  <  k2 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -) ) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),  (Y, -),(-,  X, -),  1,M,1,k2) 

att  s>*jS 

agg[k1,k2]    att  agg[k1 ,  k2] 

0  0 

agg  =  LIST  or  BAG 

/*  Since  the  same  X  instance  can  be  repeatedly  used  as  elements  of  an  instance  of  the  newly  defined  class 
Y,  the  number  of  elements  of  each  Y  instance  is  checked  by  counting  the  associations  of  the  Y  instance. 
That  is,  the  value  of  count(y  *>  X)  must  be  within  the  range  specified  by  [kl,  k2]. 
However,  Y  :  X  =  [1,M]  :  [l,k2].  The  minimum  number  of  X  instances  that  a  Y  instance  can  be 
associated  with  is  ONE  (not  kl)  because  of  the  same  reason.  */ 
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•  O-C-04  (  Y,  k1 ,  k2,  X  ) 

Up  <p 

MB(  Y,  self-naming,  -,  ARRAY,  X,  Py,  - ) 
Py  =  forall  y:Y  suchthat  count(y  *>  X)  =  |k2  -  k1  +  1 1 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -) ) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),  (Y,-),(-,X,-),1,M,1,k2) 

ARRAY[k1 ,  k2]     ARRAY[k1 ,  k2] 

(!)  (?) 

/*  The  kl  and  k2  specifies  the  minimum  and  maximum  index  values  of  the  array  so  that  each  instance 
of  the  newly  defined  class  Y  represents  a  fixed  number  (i.e.,  Ik2  -  kl  +  1 1)  of  X  instances,  where 
kl  and  k2  are  positive  or  negative  integer  numbers. 
The  elements  of  each  Y  instance  can  be  duplicated  X  instances.  */ 


•  O-C-05(X,  (Y1  Yn)) 

MB(  X,  self-naming,  -,  TUPLE,  (Y1  Yn),  -,  - ) 

PT(  X,  -,  count(X),  count(X),  (-,  Yi,  -)  ) 

PT(  Yi,  -,  0,  count(Yi),  (-,  X,  -) ) 

CD(  (-),  (X,  -),((-,  Y1,-)...  (-,  Yn,  -)).  1,1,1,1  ) 

CD(  (-),  (X, -),(-,  Yi, -),  1,M,  1,1)    i  =  1  ..n 

•  O-C-06  (  X,  (att1  attn) ) 

an 

E-class 

X  is  not  a 
class,  or  c 

X 

sub-class, 
ross-produ 

attl^ 

A<£ 

attn 

composition 
ct  class. 

MB(  X,  system-named,  (att1  attn),  -,  E-CLASS,  -,  - ) 

•O-C-07(Y,  SET,  k1,k2,X) 

z 

MB(  Y,  system-named,  -,  SET,  X,  -,  - ) 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -) ) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD(  (-),  (Y,  -),(-,  X,  -),  1,M,k1,k2) 

all 

SETfkl ,  k2] 

X 

/*  Same  as  O-C-02  except  that  the  new  class  Y  is  defined  on  an  entity-class  X.  */ 
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•  O-C-08  (  Y.agg,  k1,  k2,  X) 

Z 

MB(  Y,  system-named,  -,  agg,  X,  Py,  - ) 
Py  =  forall  y  in  y:Y  suchthat  k1  <  count(y  *>  X)  <  k2 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -) ) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD(  (-),  (Y,  -),(-,  X,  -),  1,M,  1,k2) 

399  = 
LIST,  BAG 

att 

agg[kl,k2] 

X 

•  O-C-09  ( Y,  k1 ,  k2  X) 

z 

MB(  Y,  system-named,  -,  ARRAY,  X,  Py,  - ) 
Py  =  forall  x  in  x:X  *>  Y  suchthat 
count(x  *>  Y)  =  |k2  -  k1  +  1 1 
PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -) ) 
PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 
CD((-),(Y, -),(-,  X,  -),  1,M,|k2-k1+1|,  |k2-kW1|) 

att 

ARRAY[k1 ,  k2] 

X 

•  O-C-10  (X,  Y,  (att1  attn) ) 

G  < 

I 

X 

MB(  X,  system-named,  (att1  attn),  -,  Y,  -,  -) 

/*  X  is  the  subclass  of  Y  and  only  Y,  whose  primary  key  is  inherited  from  Y.  */ 


•  O-T-10-1  (X,  (Y1,  ...,Yn)) 

MB(  X,  system-named,  -,  -,  Y,  -,  -) 

Y1 

I 

Yn 

G 

X 

G 

/*  X  is  a  subclass  of  multiple  classes,  Yl...Yn.  */ 


•  O-C-1 1  (  X,  att,  dom(att) ) 

X 

-     att  [agg] 

"  OPTIONAL 

PT(  X,  -,  0,  count(X),  (att,  dom(att),  -) ) 

PT(  dom(att),  -,  0,  count(dom(att)),  (att1,  X,  -) ) 

CD(  (-),  (X,  -),  (att,  dom(att),  -),  1,M,  1,1  ) 

/*  This  pattern  captures  the  constraints  existed  between  X  and  the  domain  of  the  optional  attribute  'att'.  */ 
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•  O-T-11-1  (X,  att,  dom(att) ) 

X 

.     att  [agg] 

A  

PT(  X,  -,  count(X),  count(X),  (att,  dom(att),  -) ) 
PT(  dom(att),  -,  0,  count(dom(att)),  (att1,  X,  -) ) 
CD(  (-),  (X,  -),  (att,  dom(att),  -),  1,  M,  1, 1  ) 

/*  The  attribute  'att'  is  a  non-null  attribute.  */ 


•  O-T-11-2  (X,  att,  dom(att) ) 

X 

-     att  [agg] 

"  OPTIONAL  TPV_-/ 

PT(  X,  0,  count(X),  (att,  dom(att),  -) ) 

PT(  dom(att),  -,  count(dom(att)),  count(dom(att)), 

(att-1,  x,  -) ) 
CD(  (-),  (X,  -),  (att,  dom(att),  -),  1 ,  M,  1 , 1  ) 

/*  The  instances  of  the  domain  of  'att'  are  totally  participated  in  this  association.  */ 


•  0-T-11-3(X,  att,  dom(att)) 

X 

.     att  [agg] 

"  OPTIONAL  1-1  \_y 

PT(  X,  -,  0,  count(X),  (att,  dom(att),  -) ) 

PT(  dom(att),  -,  0,  count(dom(att)),  (att1,  X,  -) ) 

CD(  (-),  (X,  -),  (att,  dom(att),-),  1,1,1,1  ) 

/*  The  same  instance  of  the  domain  of  'att'  cannot  be  the  attribute  values  of  different  X  instances.  */ 


•  O-C-12  (X,  att,  dom(att) ) 


X 


att  [agg] 

OPTIONAL 

PT(  X,  -,  0,  count(X),  (att,  dom(att),  -) ) 

PT(  dom(att),  -,  0,  count(dom(att)),  (att1,  X,  -) 

CD(  (-),  (X,  -),  (att,  dom(att), -),  1.M,  1,1  ) 


/*  Same  as  O-C-l  1  except  that  the  domain  of  'att'  is  defined  on  an  entity-class.  */ 


•  O-T-12-1  (X,  att,  dom(att) ) 


X 


att  [agg] 


PT(  X,  -,  count(X),  count(X),  (att,  dom(att),  -) ) 
PT(  dom(att),  -,  0,  count(dom(att)),  (att  1  X,  -) ) 
CD(  (-),  (X,  -),  (att,  dom(att),  -),  1,  M,  1, 1  ) 


•  O-T-12-2  (X,  att,  dom(att) ) 


X 


att 


[agg] 


OPTIONAL  TP 


PT(  X,  0,  count(X),  (att,  dom(att),  -) ) 

PT(  dom(att),  -,  count(dom(att)),  count(dom(att)) 

(atf1,  X,  -) ) 
CD((-),  (X,  -),  (att,  dom(att),-),1,M,  1,1  ) 
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•  0-T-12-3(X,  att,  dom(att)) 


X 


att  [agg] 


OPTIONAL  1-1 


PT(  X,  -,  0,  count(X),  (att,  dom(att),  -) ) 

PT(  dom(att),  -,  0,  count(dom(att)),  (att1 ,  X,  -) ) 

CD((-),  (X, -),  (att,  dom(att),-),  1,1,1,1  ) 


•  O-T-1 1 1 2-4  (  X,  ((att1 ,  dom(att1 ))  (attn,  dom(attn))) ) 

CD(  (-),  (X,  -),  ((att1,dom(att1), -)  

(attn,  dom(attn),  -)),  1, 1,1,1) 

attrr^^ 

/*  The  attributes  attl...attn  together  form  a  composite  primary  key  of  X,  if  n  >  1.  Otherwise,  attl  is 
a  simple  primary  key.  Each  attribute  of  this  key  must  also  be  a  non-null  attribute.  */ 


•  O-C-13  (X,  Y, 

-) 

IH(  X,  Y) 

X 

G  — 

Y 

PT(  X,  -,  0,  count(X),  (-,  Y,  -) ) 

PT(  Y,  -,  count(Y),  count(Y),  (-,  X,  -) ) 

CD((-),  (X,  -),(-,  Y,-),  1,1,1,1  ) 

/*  This  pattern  captures  the  subclass-superclass  semantics.  */ 


•0-C-14(X,  (Y1  Yn)) 

Y1 

LD(X,  (Y1..Yn), 

forall  x  in  (x:X)  suchthat  exist  y1  yn  in 

(x  OR(*>y1:Y1  *>  yn:Yn) ) 

x    G<Qsi  j 

Yn 

/*  The  same  object  can  be  in  subclasses  Yl...Yn.  */ 


•O-T-1 4-1  (X,  (Y1  Yn)) 


LD(  X,  (Y1..Yn),  expl  ) 
expl  = 

(forall  x  in  (x:X  *>  Y1)  suchthat  NOT  exist  y2  ...  yn  in 
(x  OR(*>  y2:Y2  *>  yn:Yn)))  AND   AND 

(forall  x  in  (x:X  *>  Yn)  suchthat  NOT  exist  y1  ...  yn-1  in 
(xOR(*>y1:Y1  *>  yn-1:Yn-1))) 


/*  The  objects  of  the  subclasses  Yl...Yn  must  be  mutually  exclusive.  */ 
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O-T-14-2  (X,  (Y1,...,Yn)) 


LD(X,  (Y1..Yn),exp2) 
exp2  = 

(forall  x  in  (x:X  *>  Y1)  suchthat  exist  y2  ...  yn  in 

(x  AND(*>  y2:Y2  *>  yn:Yn)))  AND   AND 

(forall  x  in  (x:X  *>  Yn)  suchthat  exist  y1  ...  yn-1  in 
(x  AND(*>  y1  :Y1  *>  yn-1  :Yn-1 ))) 


/*  If  an  object  is  in  one  of  the  subclass  Yi  with  an  instancerepresentation,  then  it  must  also  be  in  all  other 
subclasses  within  its  different  instance  representations.  */ 


•0-T-14-3(X,  (Y1.Y2)) 

SS^ 

Y1 

LD(X,  (Y1.Y2),  exp3) 
exp3  = 

forall  x  in  (x:X  *>  Y1)  suchthat  exist  y2  in  (x  *>  y2:Y2) ) 

x  GO 

ST^ 

Y2 

/*  The  set-subset  (or  ST-SS)  constraint  requires  that  if  an  X  object  is  in  the  subclass  Yl 
then  it  must  also  be  in  Y2.  However,  the  reverse  is  not  necessary  true.  */ 


•  0-T-14-4(X,  (Y1  Yn)) 

Y1 

PT(  X,  -,  count(X),  count(X),  ((-,  Y1,  -), ..,  (-,  Yn,  -))) 

X  G< 

TP  x 

Yn 

/*  The  'TP'  specifies  a  total-specialization  constraint.  */ 


•  O-C-15  (  X,  att,  Y  ) 

PT(  X,  -,  count(X),  count(X),  (att,  Y,  -) ) 
PT(  Y,  -,  0,  count(Y),  (att1,  X,  -) ) 
CD(  (-),  (X,  -),(att,Y,  -),  1,M,  1,1  ) 

x  I—*1— 

Y 

•  O-T-15-1  (  X,  att,  Y  ) 

PT(  X,  -,  count(X),  count(X),  (att,  Y,  -) ) 
PT(  Y,  -,  count(Y),  count(Y),  (art  \  X,  -) ) 

X 

j  att 

TP 

Y 

CD(  (-),  (X,  -),(att,Y,  -),  I.M.1,1  ) 
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•  O-T-15-2  (  X,  (att1 ,  Y1),  (att2,  Y2),  p1 ,  q1 ,  p2,  q2  ) 

axxM  Y1 

[p1,q1]  I  

x  |l< 

[p2,  q2]   

attfj  Y2 

CD(  (att1 ,  Y1 ,  -),  (X,  -),  (att2,  Y2,  -),  p1 ,  q1 ,  p2,  q2  ) 

/*  Yl  :  Y2  =  [pl.ql]  :  [P2,q2]  */ 


•  O-C-16  (  X,  (att1 , attn),  (Y1  Yn) ) 

MB(  X,  system-named,  (att1...attn),  SET, 
ENTITY_OBJECT,  Px,  - ) 

Px  =  (exist  x  in  (x:X  where  x  =  lnstance(Y1)))  AND 
AND 

(exist  x  in  (x:X  where  x  =  Instance(Yn))) 

X 

^attl  \ 
attn  T 

c 

Y1  ■■■■ 

Yn 

•  0-C-17(X,  (att1, ....  attn),  (Z1,...,Zn)) 

MB(  Y,  system-named,  (att1  ...attn),  SET, 
ENTITY_OBJECT,  Py,  - ) 

Y 

(zi) 

X 

(Zk) 

Py  = 

(exist  y  in  (y:Y  where  y.Z1  =  z1 1  AND  ..  AND  y.Zk  =  zk1 )) 
AND 

(exist  y  in  (y:Y  where  y.Z1  =  212  AND  ..  AND  y.Zk  =  zk2)) 
AND  ...  AND 

(exist  y  in  (y:Y  where  y.Z1  =  z1  m  AND  ..  AND  y.Zk  =  zkh)) 

APPENDIX  C 

EQUIVALENCE  MATRICES  FOR  DATA  MODEL  TRANSLATIONS  OF 
EXPRESS,  IDEF-1X,  NIAM,  AND  OSAM* 


C.l  EXPRESS-to-IDEF-lX 


EXPRESS 

(source) 

IDEF-1X 

(target) 

E-C-01 

• 
• 

• 
• 

• 
• 

E-C-12 

• 
• 

E-C-13 

l-C-01  - 

MB(I-C-01)  + 

MB(E-C-13) 

E-C-14 

l-C-03  - 

MB(l-C-03)  + 

MB(E-C-14) 

E-T-14-1 

E-C-15 

l-C-04 

L   1  -  1  O  1 

E-C-16 

l-C-05 

E-T-16-1 

l-T-05-1 

E-T-1516-2  = 

l-T-04-2 

E-T-1516-3  = 

E-T-1516-4  = 

E-T-1516-5  = 

E-C-17 

l-C-10  - 

LD(I-C-10) 

E-C-18 

l-C-11  - 

LD(I-C-11) 

E-T-18-1 

l-C-11 

E-C-19 

E-T-19-1 

E-T-1819-2  = 

l-T-11-1 

-  LD(I-T-11-1) 

132 


133 


C.2  IDEF-lX-to-EXPRESS 


IDEF-1X 

EXPRESS 

(source) 

(target) 

l-C-01 

b-G-13  -  MB(b-U-lo)  +  Md(l-L>-U  l ) 

l-C-02 

b-G-lo  -  MB(t-O-lo)  +  Md(\-L>-U£.) 

l-C-03 

b-G-14  -  MB(b-0- 14)  +  Md(I-U-Uo) 

l-C-04 

b-G-1 5 

l-T-04-1  = 

b- 1  -15-1 

l-T-04-2  = 

b-l-151b-^ 

l-C-05 

b-O-1 6 

l-T-05-1  = 

b- 1  -16-1 

l-C-06 

b-G-1  b  -  r  1  (b-O-lb,       +  r  1  (l-L>-Ub, 

l-T-06-1  = 

b-l-1b-1  -  r  1  (b- 1  -1  b-1 ,  d)  +  r  1(1- 1  -Uo-1 ,  d) 

l-C-07  = 

E-C-16  -  CD(E-C-16)  +  CD(l-C-07) 

l-T-07-1  = 

E-T-16-1  -  CD(E-T-16-1)  +  CD(l-T-07-1) 

l-C-08  = 

E-C-16  -  CD(E-C-16)  +  CD(l-C-08) 

l-T-08-1  = 

E-T-16-1  -  CD(E-T-16-1)  +  CD(l-T-08-1) 

l-C-09  = 

E-C-16  -  CD(E-C-16)  +  CD(l-C-09)  -  PT(E-C-16,  2)  +  PT(l-C-09,  2) 

l-T-09-1  = 

E-T-16-1  -  CD(E-T-16-1)  +  CD(l-T-09-1)  -  PT(E-T-16-1,  2)  +  PT(l-T-09-1 ,  2) 

l-C-10  = 

E-C-17  +  LD(I-C-10) 

l-C-11 

E-T-18-1 

l-T-11-1  = 

E-T-18-1  +  E-T-1819-2 
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C.3  EXPRESS-to-NIAM 


FYDRFQQ 
CArncoo 

/  cni  1  tpp^ 

Ml  AM 

(taraeO 

E-C-01 

N-C-02  - 

CD(N-C-02) 

+  CD(E-C-01) 

E-C-02 



E-C-03 



E-T-03-1 



E-T-03-2 



E-T-03-3 



E-C-04 

N-C-05  - 

CD(N-C-05) 

+  CD(E-C-04) 

E-C-05 



E-C-06 

— 

E-T-06-1 



E-T-06-2 



E-T-06-3 



E-C-07 

N-C-01 

E-C-08 

N-C-01 

E-C-09 



E-C-10 

— 

E-C-1 1 

— 

E-C-12 

— 

E-C-1 3 

N-C-03 

E-C-1 4 

N-C-04 

E-T-14-1 

N-T-04-1 

E-C-1 5 

N-C-06 

E-T-15-1 

N-T-06-1 

E-C-1 6 

N-C-06 

E-T-16-1 

N-T-07-1 

E-T-1516-2  = 

N-C-14 

tz  I  -  I  O  I  D  O 

E-T-1516-4  = 

N-T-07-7 

E-T-1516-5  = 

E-C-1 7 

N-C-15 

E-C-1 8 

N-C-16 

E-T-18-1 

N-T-16-2 

E-C-1 9 

E-T-19-1 

E-T-1819-2  = 

N-T-16-1 
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C.4  NIAM-to-EXPRESS 


NIAM 

(source) 

EXPRESS 

(target) 

N-C-01 

E-C-08 

N-C-02 

E-C-01 

N-T-02-1  = 

E-C-01  -  CD(E-C-01)  + 

CD(N-T-02-1) 

N-C-03 

E-C-13 

N-C-04 

E-C-14 

N-T-04-1  = 

E-T-14-1 

N-C-05 

E-C-04 

N-C-06 

E-C-15 

N-T-06-1  = 

E-T-15-1 

N-T-06-2  = 

E-C-15  +  E-T-1516-2 

N-T-06-3  = 

E-T-15-1  +  E-T-1516-2 

N-T-06-4  = 

E-C-15 

N-T-06-5  = 

E-T-15-1 

N-T-06-6  = 

E-C-15  +  E-T-1516-2 

N-T-06-7  = 

E-T-15-1  +  E-T-1516-2 

N-C-07  = 

E-C-16 

N-T-07-1  = 

E-T-16-1 

N-T-07-2  = 

E-C-16  -  PT(E-C-16,  2) 

+  PT(N-T-07-2,  2) 

N-T-07-3  = 

E-C-16  +  E-T-1516-2 

N-T-07-4  = 

E-T-16-1  +  E-T-1516-2 

N-T-07-5  = 

E-C-16  +  E-T-1516-2  - 

PT(E-C-16,2)  +  PT(N-T-07-5,  2) 

N-T-07-6  = 

E-C-16 

N-T-07-7  = 

E-T-16-1 

N-T-07-8  = 

E-C-16  -  PT(E-C-16,  2) 

+  PT(N-T-07-8,  2) 

N-C-08 

• 

• 
• 

• 
• 

N-C-16  = 

N-C-17  = 

E-T-1516-2 

(N-T-17-1) 

N-C-18  = 

E-C-17 

N-C-19  = 

E-C-18 

N-T-19-1  = 

E-T-1819-2 

N-T-19-2  = 

E-T-18-1 
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C.5  EXPRESS-to-OSAM* 


EXPRESS 

(source) 

OSAM* 

(target) 

E-C-01 

E-C-02 

U-O-Uo 

E-C-03 

E-T-03-1 

U-O-04 

E-T-03-2 

E-T-03-3 

E-C-04 

U-O-0/ 

E-C-05 

/A  AO 

E-C-06 

E-T-06-1 

f~\    /"\  AO 

(J-G-09 

E-T-06-2 

E-T-06-3 

E-C-07 

U-U-U  1 

E-G-08 

O  P  Hi 

U-O-Ul 

E-C-09 

E-0-1 0 

E-0- 1 1 

E-L/-1 2 

E-O- 1  o 

\J-\j-UO 

C  P  1  /I 
E-L»- 1 4 

n  r  m 
kj-o- 1  u 

E- 1 -14-1 

A  T  1(1  1 

E-O-i  b 

O  P  1 1 
U-O- I  I 

t- I -1  0-1 

\J-  I  -  I  I  -  I 

E-O- 1  b 

U-L<- l£ 

E- 1  -  lb- 1 

r~  ~T~  4  rj  ^  o 

E- 1  -1bib-2 

U- 1  - 1 11  £-4 

E-T-1516-3 

= 

E-T-1516-4 

E-T-1516-5 

E-C-17 

0-C-13 

E-C-18 

0-C-14 

E-T-18-1 

0-T-14-1 

E-C-19 

E-T-19-1 

E-T-1819-2 

O-T-14-4 
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C.6  0SAM*-to-EXPRESS 

OSAM* 

EXPRESS 

(source) 

(target) 

U-O-01 

_  no 
b-O-Oo 

=    c  a  m 

U-C-03 

b-L>-02 

O-C-04 

=  E-T-03-1 

O-C-05 

-    E-C-13  -  MB(E-C-13)  +  MB(O-C-05) 

O-C-06 

fc-C-13  -  MB(E-C-13)  +  MB(O-C-Ob) 

O-C-07 

b-C-04 

r\  no 

b-O-05 

a*\  /*»  /in 

u-o-uy 

-     h- 1  -Ub-1 

U-O-10 

b-G-14  -  Mb(b-G-14)  +  MB(O-C-10) 

U- 1  -1 0-1 

-     b- 1 -14-1 

A  p    4  H 

U-O-1 1 

b-C-15 

U- 1  -11  -1 

-  b-l-1o-1 

U- 1  -1 1-£ 

U- 1-11-3 

=  FAIR 

AT  19  1 

=      C  T  it  1 
C-  I  -  I  D-  I 

U- 1  -1  d-c 

U-  1  -1  <c-o 

A  T  1HO  yl 

r  t  icic  o 
-  b-l-ioib-<: 

n  a  ii 

—      r  p  <7 
b-O- 1  / 

U-L>- 14 

—      C  A  1Q 

O-T-14-1 

=  E-T-18-1 

O-T-14-2 

=    E-C-18  -  LD(E-C-18)  +  LD(0-T-14-2) 

O-T-14-3 

=    E-C-18  -  LD(E-C-18)  +  LD(0-T-14-3) 

O-T-14-4 

=  E-T-1819-2 

O-C-15 

=  E-T-16-1 

O-T-15-1 

O-T-15-2 

O-C-16 

O-C-17 
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C.7  IDEF-lX-to-NIAM 


IDEF-1X 

(source) 

NIAM 

(target) 

I-O-01 

m  no 

N-O-03  - 

Md(I\I-C-03)  + 

Md(I-O-01) 

l-G-02 

k  i  AO 

N-G-03  - 

1  1  n  /  K  1   O  AO\ 

MB(N-C-Oo)  + 

Pi  A  O  /  1            A  0\ 

MB(l-C-02) 

l-G-03 

N-G-04  - 

MB(N-G-04)  + 

i  in/i  ao\ 

MB(l-G-03) 

i  r\A 

IN-O-Ub 

I-T.fl4-1 

I-T-D4-? 

IN    1     1 H  1 

IN  \«/  U / 

I    1  1 

M-T-D7-1 

IN    I    U/  1 

M  T  ("17  9 

IN-  1  "U /  c. 

l- 1  -Uo-l 

In-  I  -U/ - 1 

+  N-T-07-2 

l-C-07 

= 

N-T-07-3 

l-T-07-1 

N-T-07-4 

l-C-08 

N-C-07  - 

CD(N-C-07)  + 

CD(l-C-08) 

l-T-08-1 

N-T-07-1 

-  CD(N-T-07-1) 

+  CD(l-T-08-1) 

l-C-09 

N-T-07-2 

-  CD(N-T-07-2) 

+  CD(l-C-09) 

l-T-09-1 

N-T-07-1 

+  N-T-07-2  -  CD(N-T-07-1)  +  CD(l-T-09-1) 

l-C-10 

N-C-15  + 

LD(I-C-10) 

l-C-11 

N-T-16-2 

l-T-11-1 

N-T-16-1 

+  N-T-16-2 
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C.8NIAM-to-IDEF-lX 


NIAM  IDEF-1X 

(source)  (target) 


N-C-01  =  — 

N-C-02  =  — 

N-T-02-1  =  — 

N-C-03  =  l-C-01  -  MB(I-C-01)  +  MB(N-C-03) 

N-C-04  =  l-C-03  -  MB(l-C-03)  +  MB(N-C-04) 

N-T-04-1  =  — 

N-C-05  =  — 

N-C-06  =  l-C-04 

N-T-06-1  =  l-T-04-1 

N-T-06-2  =  l-C-04  -  CD(l-C-04)  +  CD(N-T-06-2) 

N-T-06-3  =  l-T-04-1  +  l-T-04-2 

N-T-06-4  =  l-C-04 

N-T-06-5  =  l-T-04-1 

N-T-06-6  =  l-C-04  -  CD(l-C-04)  +  CD(N-T-06-6) 

N-T-06-7  =  l-T-04-1  +  l-T-04-2 

N-C-07  =  l-C-05 

N-T-07-1  =  l-T-05-1 

N-T-07-2  =  l-C-06 

N-T-07-3  =  l-C-07 

N-T-07-4  =  l-T-07-1 

N-T-07-5  =  l-C-09(X,  a,  Y,  1,  1) 

N-T-07-6  =  l-C-05 

N-T-07-7  =  l-T-05-1 

N-T-07-8  =  l-C-06 

N-C-08  =  — 


N-C-13  =  — 

N-C-14  =  — 

N-T-14-1  =  l-T-04-2 

N-C-15  =  l-C-10  -  LD(I-C-10) 

N-C-16  =  l-C-11  -  LD(I-C-11) 

N-T-16-1  =  l-T-11-1  -  LD(I-T-11-1) 

N-T-16-2  =  l-C-11 
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C.9  IDEF-lX-to-OSAM* 


IDEF-1X 

(source) 

OSAM* 

(target) 

l-C-01 

= 

O-C-06 

l-C-02 

= 

O-C-06 

l-C-03 

■ 

O-C-10 

l-C-04 

= 

O-C-1 1 

l-T-04-1 

O-T-11-1 

l-T-04-2 

= 

O-T-1112-4 

l-C-05 

— 

O-C-1 2 

l-T-05-1 

— 

O-T-12-1 

l-C-06 

= 

O-T-12-2 

l-T-06-1 

O-T-12-1  +  O-T-12-2 

l-C-07 

— 

O-T-12-3 

l-T-07-1 

O-T-12-1  +  O-T-12-3 

l-C-08 

O-C-1 2  -  CD(0-C-12)  +  CD(l-C-08) 

l-T-08-1 

O-T-12-1  -  CD(0-T-12-1)  +  CD(l-T-08-1) 

l-C-09 

O-T-12-2  -  CD(0-T-12-2)  +  CD(l-C-09) 

l-T-09-1 

O-T-12-1  +  O-T-12-2  -  CD(0-T-12-1)  +  CD(l-T-09-1) 

l-C-10 

O-C-13  +  LD(I-C-10) 

l-C-11 

O-T-14-1 

l-T-11-1 

O-T-14-1  +  O-T-14-4 
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C.10OSAM*-to-IDEF-lX 


OSAM* 

(source) 

IDEF-1X 

(target) 

U-L»-U  I 

U-0-U<i 

U-O-Uo 

U-O-04 

u-o-uo 

U-O-Ub 

U-O-Uo 

U-O-09 

U-O- 10 

—       1  ^  U  J 

U- I -I U- l 

n  t  1 1  1 

l-T-04-1 

D-T-1  1 -9 
\J  III  c 

n  t  11  •? 

l-C-04  - 

l-C-05 

l-T-05-1 

n  T  19  9 

=  l-C-OR 

C\  T  1  9  Q 

1-0-07 

n  t  1119  /i 

=  I-T-04-? 

l-C-10  - 

LDM-C-1 0\ 

l-C-11  - 

1   W    1  I 

1  DM-C-1 1 ) 

O-T-14-1 

=  l-C-11 

O-T-14-2 

=     l-C-11  - 

LD(I-C-11)  + 

LD(0-T-14-2) 

O-T-14-3 

=     l-C-11  - 

LD(I-C-11)  + 

LD(0-T-14-3) 

O-T-14-4 

=  l-T-11-1 

-  LD(I-T-11-1) 

O-C-15 

=  l-T-05-1 

O-T-15-1 

=  l-T-06-1 

O-T-15-2 

O-C-16 

O-C-17 
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C.ll  NIAM-to-OSAM* 


NIAM 

(source) 

OSAM* 

(target) 

N-C-01 

=  O-C-01 

N-C-02 

=  O-C-02 

N-T-02-1  = 

.    O-C-02  - 

CD(O-C-02) 

+  CD(N-T-02-1) 

N-C-03 

=    O-C-06  - 

MB(O-C-06) 

+  MB(N-C-03) 

N-C-04 

=    O-C-10  - 

MB(O-C-10) 

+  MB(N-C-04) 

N-T-04-1  = 

■  O-T-10-1 

N-C-05 

=  O-C-07 

N-C-06 

=    O-C-1 1 

N-T-06-1  = 

=  O-T-11-1 

N-T-06-2  = 

.  O-T-11-3 

N-T-06-3  = 

=  O-T-11-1 

+ 

O-T-1 1  -3 

N-T-06-4  = 

=    O-C-1 1 

N-T-06-5  = 

=  O-T-11-1 

N-T-06-6  = 

=  O-T-11-3 

N-T-06-7  = 

=  O-T-11-1 

+ 

O-T-11-3 

N-C-07  = 

=    O-C-1 2 

N-T-07-1  = 

=  O-T-12-1 

N-T-07-2  = 

.  O-T-12-2 

N-T-07-3  = 

O-T-12-3 

N-T-07-4  = 

O-T-12-1 

+ 

O-T-12-3 

N-T-07-5  = 

O-T-12-2 

+ 

O-T-12-3 

N-T-07-6  = 

O-C-1 2 

N-T-07-7  = 

O-T-12-1 

N-T-07-8  = 

O-T-12-2 

N-C-08 

• 

• 
• 

• 

N-C-16  = 

• 

N-C-17  = 

N-T-17-1  = 

O-T-1112-4 

N-C-18  = 

O-C-1 3 

N-C-19  = 

O-C-1 4 

N-T-19-1  = 

O-T-14-4 

N-T-19-2  = 

O-T-14-1 

143 


C.12  0SAM*-to-NIAM 


OSAM* 

(source) 

NIAM 

(target) 

O-C-01 

N-C-01 

O-C-02  ' 

=      N-C-02  - 

CD(N-C-02)  + 

CD(O-C-02) 

O-C-03 

O-C-04 

O-C-05 

O-C-06 

K  i  o  nrt 

=     N-G-03  - 

MB(N-C-03)  + 

MB(O-C-06) 

O-C-07 

N-C-05  - 

CD(N-C-05)  + 

CD(O-C-07) 

O-C-08 

O-C-09 

= 

O-C-10 

N  C-04  - 

MB(N-C-04)  + 

MB(O-C-10) 

O-T-10-1 

N-T-04-1 

O-C-1 1 

N-C-06 

O-T-11-1 

N-T-06-1 

O-T-11-2 

N-C-06  - 

PT(N-C-06,  2) 

+  PT(0-T-11-2,  2) 

O-T-11-3 

N-T-06-2 

O-C-1 2 

=  N-O-07 

O-T-12-1  = 

M  T  A7  H 

O-T-1 2-2 

=     N- 1  -07-2 

O-T-1 2-3 

=     N- 1 -07-3 

O-T-1 11 2-4  = 

=  N-l-14-1 

O-C-1 3  = 

=  N-O-lb 

O-C-1 4  = 

O-T-1 4-1 

=  N-T-16-2 

O-T-1 4-2 

=     N-C-16  + 

LD(0-T-14-2) 

O-T-1 4-3 

=     N-C-16  + 

LD(0-T-14-3) 

O-T-1 4-4 

N-T-16-1 

O-C-1 5 

N-T-07-1 

O-T-1 5-1 

N-T-07-1 

+  N-T-07-2 

O-T-1 5-2 

O-C-1 6 

O-C-1 7 
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